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Preface 


This  report  presents  the  analysis  and  design  of  a 
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in  this  report  was  performed  in  support  of  the  Automated 
Management  System  (AMS)  which  is  being  development  by  the 
Aeronautical  Systems  Division  (ASD).  It  is  hoped  that  the 
design  will  result  in  added  capabilities  for  the  existing 
network  in  the  near  future  and  that  it  will  also  aid 
planning  efforts  for  full  scale  development  of  the  AMS 
Network . 
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Abstract 

'A  resource-sharing  (R-S)  computer  network  link  design 
is  presented.  The  design  complies  with  requirements  for  the 
Automated  Management  System  (AMS)  being  developed  by  the  Air 
Force’s  Aeronautical  Systems  Division  (ASD).  The  design 
includes  Texas  Instruments  Model  990  computers  that 
currently  exist  in  the  AMS  Network. 

R-S  software  was  designed  that  binds  existing  modules 
into,  effectively,  one  R-S  process  at  each  end  of  the  link. 
The  two  R-S  processes  cooperate  in  accordance  with  R-S 
protocols  to  accomplish  the  specified  R-S  functions. 
Existing  capabilities  of  the  DX-10  operating  system  were 
used  extensively.  The  processes  communicate  via  telephone 
circuits  using  Ti  3780  Emulator  software  and  standard  data 
communications  hardware.  The  R-S  functions  implemented 
include  file  transfer,  program  file  transfer,  and  remote 
program  execution,  as  well  as  others. 

A  unique  interface  to  the  DX-10  operating  system  was 
designed  to  allow  the  R-S  software  to  have  adequate  access 
to  the  operating  system.  The  operating  system  batch  command 
was  emulated,  allowing  the  R-S  program  to  construct  a  "batch 
file"  containing  any  operating  system  commands  that  would 
normally  be  entered  from  a  interactive  terminal. 
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I.  Introduction 


As  the  benefits  of  computers  in  the  business  and  office 
environment  have  become  more  widely  known,  the  demand  for 
computer-based  management  information  services  has  increased 
dramatically.  Management  information  applications  usually 
involve  large  amounts  of  data  and  specialized  computer 
programs  are  required  to  analyze  the  data.  However,  many  of 
these  applications  are  beyond  the  scope  of  the  mini-computer 
systems  that  can  be  economically  utilized  in  the  office 
environment.  Fortunately,  the  rapidly  advancing  computer 
networking  technology  provides  a  solution.  Networking 
allows  the  resources  of  the  larger,  more  versatile,  computer 
systems  to  be  shared  with  the  smaller  office  computers. 

The  Air  Force's  Aeronautical  Systems  Division  (ASD)  is 
planning  the  development  of  the  Automated  Management  System 
(AMS)  which  will  provide  a  large  variety  of  management 
information  services  to  the  managers  of  Air  Force  weapons 
system  development  programs.  The  services  will  include  the 
maintenance  of  large  data  bases,  analysis  of  data  bases,  and 
the  creation  of  reports  and  graphical  presentations.  AMS 
will  consist  of  30  small  computers  systems  and  at  least  5 
large  computer  systems.  The  computers  will  be 
interconnected  by  a  data  communications  subnetwork  to  create 


the  AMS  Computer  Network.  The  networking  of  the  computers 
will  allow  each  site  to  share  the  resouces  of  the  other 
computers  in  the  network.  The  objective  of  this 
investigation  was  to  take  the  first  step  toward  realizing 
the  AMS  resource-sharing  (R-S)  computer  network  by  designing 
a  single  R-S  link.  The  link  was  constrained  to  consist  of 
two  Texas  Instruments  Inc.  Model  990  computer  syst'  *  ■. 

AMS  Definition 

The  ASD  Automated  Management  System  (AMS)  is  an 
evolving,  computer-based  management  information  system  that 
aids  managers  of  Air  Force  weapon  system  development 
programs  by  storing  and  analyzing  management  data.  The 
objective  of  AMS  (Ref  1)  is  to  provide  management 
information  services  to  30  user  locations  known  as  sites. 
AMS  will  allow  managers  direct  access  to  the  provided 
services.  The  ease  of  operation  will  be  achieved  by 
defining  a  minimum  number  of  interactive  commands  to  effect 
the  desired  services.  Ideally,  only  one  command  would  be 
needed  for  a  frequently  requested  service.  Additionally, 
any  parameters  required  with  a  command  will  be  minimized  and 
the  operator  will  be  prompted  for  the  parameters  in 
unambiguous  English. 

Since  each  site  is  a  computer  system,  many  of  the 
simpler  management  information  services  can  be  provided 
autonomously  by  the  site.  For  instance,  the  accounting  of 


office  travel  funds  is  a  very  localized  service  that 
requires  limited  storage  and  relatively  simple  processing, 
and  is,  therefore,  within  the  capability  of  a  site. 
However,  the  analysis  of  cost  data  for  an  aircraft 
development  program  might  require  the  resources  of  a  large 
computer  system.  The  resources  of  large,  remote  computer 
systems  will  be  available  through  the  AMS  Computer  Network. 
Before  describing  the  AMS  Computer  Network,  a  brief  tutorial 
of  computer  networks  is  presented  to  familiarize  the  reader 
with  the  terminology  and  concepts  used  in  this 
investigation. 

Network  Fundamentals 

Figure  1  illustrates  a  typical  network  topology.  In 
the  figure,  squares  represent  hosts,  circles  represent 
nodes,  and  lines  represent  physical  links.  Hosts  are  user 
computers  that  are  connected  to  other  user  computers  via  the 
network.  Nodes  are  components  of  the  data  communications 
subnetwork  and  provide  routing  and  multiplexing  functions. 
The  subnetwork  is  the  portion  of  the  network  that  logically 
ties  the  hosts  together.  The  interface  between  a  host  and 
the  subnet  is  usually  internal  to  the  host  since  the  host 
often  performs  some  of  the  subnetwork  data  communications 
functions . 

For  the  hosts  and  nodes  to  communicate  with  each  other, 
they  must  complement  each  other  physically  and  logically. 


Figure  1.  Typical  Network  Configuration 


The  participants  in  the  network  must  adhere  to 
communications  conventions,  or  protocols.  The  protocols  are 
divided  into  layers,  or  levels,  of  functions  for  ease  of 
understanding,  implementation,  and  standardization.  The 
levels  defined  by  one  particular  partitioning  scheme 
(Ref  21:66-67)  are  described  in  the  following 
subparagraphs . 

Physical .  The  physical  level  protocols  establish  a  physical 
and  electrical  communications  path.  The  physical  level  is 
considered  to  be  the  lowest  level  since  it  provides  the 
fundamental  communications  path  used  by  the  higher  level 
protocols . 

Link .  Above  the  Physical  level  protocol  is  the  link  level 
protocol  which  provides  error  control  and  some  flow 
control.  This  layer's  primary  function  is  error  protection 
which  it  provides  by  consructing  the  data  into  frames  and 
adding  error  detection  and  correction  code  bits.  Since  the 
data  is  divided  into  frames,  a  limited  flow  control  can  be 
implemented  by  labeling  the  frames  and  keeping  track  of 
which  frames  in  the  sequence  have  been  successfully 
transported.  When  an  error  is  detected,  the  flow  can  be 
stopped  while  corrective  action  is  taken  between  network 
elements . 

Network .  Next,  the  network  level  protocols  route  and 
multiplex  the  data  frames,  making  sure  that  each  frame  gets 
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to  the  next  proper  node  on  its  way  to  its  proper 
destination.  Network  protocols  concatenate  links  to 
establish  a  logical  path  between  two  hosts. 

Transport.  Above  the  network  level,  the  transport  level 
controls  the  flow  of  messages  between  two  hosts.  The 
transport  level  assumes  a  virtual  link  exists  between  the 
hosts.  In  other  words,  the  transport  level  is  "unaware"  of 
the  routing  functions  being  accomplished  by  the  network 
level.  If  there  are  several  process  pairs  communicating 
between  the  two  hosts,  the  transport  layer  provides  routing 
and  multiplexing  for  those  process  pairs. 

Session .  The  session  layer  establishes  and  maintains  the 
identities  of  the  communicating  processes.  In  other  words, 
the  session  layer  establishes  communications  between  a 
unique  pair  of  processes. 

Presentation .  The  presentation  layer  insures  that  the  data 
structures  being  used  between  two  processes  are  compatible. 
For  example,  if  it  is  necessary,  the  presentation  layer  will 
convert  a  file  to  a  common  subnetwork  format  for 
transmission.  At  the  destination  the  presentation  layer 
converts  the  common  format  to  the  local  format. 

Application.  The  highest  level  is  the  Applications,  or 
Resource-Sharing,  level.  The  applications  level  is  the  only 
layer  that  serves  the  user  directly.  The  most  elementary 
R-S  functions  are  file  access  and  file  transfer.  Other 


services  such  as  batch  processing  and  remote  terminal 
support  are  included  as  well.  All  of  the  lower  level 
protocols  exist  to  support  the  R-S  level. 

The  protocols  defined  above  are  related  to  each  other 
as  shown  in  figure  2.  The  user  data  enters  at  the  R-S 
level.  The  data  traverses  the  network  as  indicated  by  the 
line  that  threads  through  the  levels,  eventually  connecting 
the  R-S  level  of  two  hosts. 

The  protocol  levels  are  implemented  as  hardware  and 
software  processes.  A  process  corresponding  to  a  protocol 
level  will  interact  only  with  a  complementary  process  that 
implements  the  same  protocol  level.  The  horizontal  lines 
represent  the  process  interactions.  The  processes  at  each 
level  are  not  "aware"  of  lower  level  processes.  The  fact 
that  lower  level  protocols  are  transparent  is  a  major 
criterion  and  advantage  of  layering.  As  a  result,  lower 
level  protocols  can  be  replaced  or  changed  without  affecting 
the  operation  of  a  higher  level  protocol  as  long  as  the 
interface  with  the  adjacent  lower  level  process  does  not 
change. 

AMS  Computer  Network 

The  AMS  R-S  Computer  Network  will  connect  at  least  5 
large  computer  systems  and  all  of  the  sites,  including  a 
special  site  know  as  the  Software  Development  and 
Maintenance  Facility  (SDMF).  In  the  context  of  the  Network 
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Protocol  Hierarchy 


Fundamentals  section,  the  sites  would  be  known  hosts,  since 
they  are,  in  fact,  user  computers  served  by  the  network.  In 
the  context  of  AMS,  however,  they  are  classified  as  sites  to 
differentiate  them  from  the  larger  computer  systems  that  are 
know  as  hosts.  The  planned  configuration  of  the  network  is 
shown  in  Figure  3.  All  hosts  and  sites  are  connected 
directly  to  a  single  node,  forming  a  "star"  network 
topology. 

The  AMS  node  routes  and  multiplexes  data  communications 
as  was  the  case  in  the  general  network  configuration. 
However,  the  AMS  node  also  translates  the  AMS  commands  from 
the  sites  into  the  job  control  language  (JCL)  for  each 
host.  A  JCL  is  a  set  of  commands  used  to  supply  information 
to  a  computer's  operating  system  and  to  request  resources 
under  the  control  of  a  computer's  operating  system.  A 
uniform,  simple  command  set  that  eases  the  AMS  operators 
workload  is  only  possible  if  the  JCLs  of  the  hosts  can  be 
created  automatically  by  AMS. 

The  SDMF  is  a  special  site  that  is  configured  for 
efficient  program  development  activities.  It  will  be  the 
same  basic  computer  type  as  the  other  sites,  but  it  will 
have  increased  primary  and  secondary  memory  capacities,  and 
program  development  tools  such  as  editors,  assemblers, 
compilers,  and  debuggers  (Ref  18). 

Each  site  can  be  uniquely  configured,  but  the  typical 


Figure  3.  AMS  Computer  Network 


site  will  consist  of  a  small  disk  memory  (5  Megabytes)  and 
two  video  display  terminals  (VDT). 

Present  AMS  Configuration 

Since  AMS  is  an  "evolving"  management  information 
system  (MIS),  some  of  the  AMS  goals  have  been  implemented  in 
a  prototype  system.  The  present  AMS  consists  of  3  hosts,  3 
sites,  and  the  SDMF.  Some  communications  capabilities  exist 
and  several  MIS  programs  are  operational. 

Some  data  communications  capabilities  exist  in  AMS,  but 
the  computers  are  not  actively  networked.  Each  site 
communicates  with  a  host  individually  much  the  same  way  one 
would  interface  with  a  large  computer  from  a  time  sharing 
terminal.  A  computer  program  has  been  developed  that  allows 
a  site  to  communicate  with  a  host  using  asynchronous 
teletype  protocols.  Another  program  is  under  development  to 
translate  an  AMS  language  into  a  partial  set  of  the  JCL 
commands  of  the  3  hosts  (Ref  5). 

Several  MIS  programs  such  as  one  that  acquires  and 
processes  travel  fund  data  are  operational.  Many  other  MIS 
programs  are  currently  under  development. 

Scope  of  Investigation 

The  objective  of  this  investigation  was  to  design  a 
r esour ce- sh ar  i  ng  link  between  two  Texas  Instrument’s  Model- 
990  computers.  The  R-S  link  design  objectives  (Ref  3) 
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specified  the  following  capabilities: 


Sequential  File  Transfer 
Relative  Record  File  Transfer 
Intersite  Message  Transfer 
Remote  Program  Execution 
Remote  Program  Development  Capability 
These  requirements  are  a  subset  of  the  overall  AMS  Network 
requirements.  The  primary  difference  between  the  two  sets 
of  requirements  is  that  the  routing  and  multiplexing 
requirements  have  been  omitted.  Additionally,  the  existing 
components  of  AMS  were  to  be  used  to  the  maximum  extent 
possible  and  any  software  required  would  be  designed  for 
i  mp  1  erne n t a t  i  o  n  in  the  Pascal  language.  Using  existing 
components  will  reduce  the  amount  of  time  to  realize  a 
resource-sharing  capability  for  AMS.  Pascal  was  chosen  oy 
the  user  because  it  is  a  structured  language  that  results  in 
programs  that  are  easier  to  read  and,  therefore,  easier  to 
maintain.  It  is  also  hoped  that  the  Pascal  language  will 
reduce  the  development  effort. 

Approach 

The  investigation  began  with  an  analysis  of  the  AMS  R-S 
Network  Link  Requirements.  The  purpose  of  the  analysis  was 
to  determine  the  functions  necessary  to  realize  an  R-S  link 
capable  of  satisfying  the  R-S  link  system  requirements. 

Having  defined  the  basic  R-S  functions  that  would  be 
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required  to  realize  the  R-S  link,  the  existing  AMS  hardware 
and  software  modules  were  evaluated  for  their 
applicability.  Next,  a  system  design  was  accomplished  using 
applicable  existing  modules  and,  as  necessary,  newly  defined 
modules.  All  of  the  new  modules  were  software,  resulting  in 
the  remainder  of  the  investigation  concentrating  on  the 
development  of  software. 

The  software  development  began  with  a  structured 
analysis  of  the  software  requirements  to  identify  the 
processes  that  would  be  implemented  in  software.  Data  flow 
diagrams  were  used  to  illustrate  the  processes.  The  defined 
software  processes  were  next  allocated  to  software  modules 
using  structured  design  techniques.  The  resulting  modules 
were  illustrated  with  structured  design  diagrams. 

Order  of  Presentation 

Chapter  2  describes  the  analysis  of  the  system 
requirements  and  also  describes  the  system  design.  Chapter 
3  presents  the  software  requirements  analysis,  including  the 
data  flow  diagrams.  Chapter  4  describes  the  design  of  the 
necessary  software  programs  and  includes  the  structured 
design  charts  that  illustate  the  design.  Chapter  5  contains 
results  and  recommendations.  The  appendix  describes  a 
special  operating  system  interface  developed  by  this 
investigation  and  contains  program  listings  used  to 
demonstrate  and  test  the  interface. 


II. 


System  Requirements  Analysis  and  System  Design 

This  chapter  describes  the  analysis  of  the  AMS 
R  e  s o u r c e - Sh a r  i  n g  (R-S)  Computer  Network  Link  system 
requirements  and  the  design  of  the  R-S  link.  First  the 
system  requirements  were  analyzed  to  determine  the  processes 
which  must  be  implemented  in  either  hardware  or  software. 
Next,  existing  hardware  and  software  modules  were  evaluated 
for  their  applicability  to  the  system  design.  Finally,  a 
system  design  was  accomplished  that  consists  of  existing 
hardware  and  software  modules,  and  newly  defined  software 
modules . 

System  Requirements 

The  basic  requirement  for  the  AMS  R-S  computer  network 
link  was  to  create  a  R-S  network  link  between  two  Model  990 
computers  that  permits  an  operator  or  applications  process 
at  either  end  of  the  link  to  utilize  the  resources  of  both 
computers.  In  addition  to  this  basic  requirement,  it  was 
required  that  the  network  link  design  be  consistent  with  the 
overall  AMS  goals.  The  primary  AMS  goal  that  impacted  the 
link  design  was  the  goal  that  AMS  be  simple  to  operate. 

The  design  was  constrained  to  use  existing  hardware  and 
software  modules  to  maximum  extent  possible  to  reduce  the 
time  required  to  implement  the  R-S  link(Ref  3). 
Additionally,  the  following  R-S  functions  were  required  as  a 


minimum : 


Transfer  Sequential  Files 
Transfer  Program  Files 
Transfer  Intersite  Messages 
Execute  remote  programs 
Execute  remote  program  development 
To  achieve  the  goal  of  making  AMS  easy  to  operate,  it  was 
required  that  the  AMS  commands  be  limited  to  one  per  basic 
R-S  function  and  that  parameters  associated  with  each 
command  be  limited  to  those  which  can  not  be  deduced  by  the 
system  from  other  information  sources.  The  interface  to  an 
applications  program  had  to  be  correspondingly  simple  to 
minimize  applications  programming  effort  by  the  network 
user . 

System  Requirements  Analysis  System  requirements  analysis  is 
a  methodology  for  determining  what  functions,  or  processes, 
a  system  must  perform  to  satisfy  the  system  requirements. 
In  the  context  of  requirements  analysis,  the  word  process 
has  a  specific  meaning.  A  process  is  a  logical  entity, 
described  by  a  verb-object  phrase,  that  transforms  some 
other  entity,  such  as  data.  A  process  represents  the  action 
that  must  be  performed  but  does  not  specify  how  it  will  be 
implemented.  The  general  requirement  for  an  R-S  link  was 
analyzed  first  and  then  the  specific  R-S  functions  were 


analyzed . 


Figure  H  illustrates  the  most  basic  processes 
associated  with  a  R-S  link.  In  general,  there  would  be  a 
user  process  and  two  R-S  processes.  One  of  the  R-S 
processes  would  be  at  the  local,  or  initiating  end,  and  the 
other  R-S  process  would  be  at  the  remote  end.  The  using 
process  generates  R-S  commands  to  request  particular  R-S 
services  and  the  R-S  processes  cooperate  to  execute  the 
functions  indicated  by  the  commands.  The  R-S  processes  must 
cooperate  in  accordance  with  a  strict  set  of  rules,  or 
protocols  to  achieve  all  data  communications  functions  from 
the  link  level  to  the  R-S  level.  Protocols  enable  the  two 
independent,  concurrent  R-S  processes  to  synchronize  their 
activities.  Each  process  proceeds  through  a  set  of  logical 
states  which  are  determined  by  commun i cations  between  the 
processes. 

Requirements  Analysis  o f  R-S  Functions .  The  major  processes 
needed  for  each  R-S  function  are  described  in  this 
subsection.  The  processes  are  illustrated  with  Data  Flow 
Diagrams  (Ref  11).  A  Data  Flow  Diagram  (DFD)  uses  circles 
and  connecting  lines  to  represent  processes  and  interprocess 
data  flow,  respectively.  Protocols  between  the  processes 
are  not  apparent  in  DFD’s.  Protocols  determine  the  flow  of 
control  between  the  processes  and  DFD's  only  show  flow  of 
data  between  the  processes.  The  specific  protocols 
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Figure  4.  Resource-Sharing  Link 


necessary  to  implement  the  R-S  functions  will  be  described 
in  the  next  chapter. 

T  £  ci  £.s_f  e  ^  S  e_qu  e  ri_t  i.  a_l  EJUL®®.*  The  transferring  of 
sequential  files  is  the  most  elementary  and  most  common  R-S 
function.  Sequential  files  are  typically  data  files,  and, 
in  a  R-S  network,  one  would  often  want  to  transfer  a  data 
file  to  a  remote  computer  for  processing  by  a  program 
resident  in  that  computer.  A  sequential  file  could  also  be 
a  computer  language  source  file  or  a  text  file.  The  DFD  in 
figure  5  shows  the  basic  processes  required  to  tranfer  a 
sequential  file.  The  status  message  can  convey  many  types 
of  progress  information  such  as  acknowledgement  and  error. 
The  termination  message  would  vary  also.  The  termination 
messages  inform  the  user  of  a  successful  or  unsuccessful 
execution  and  provides  additional  information  to  aid 
recovery  if  the  execution  is  unsucessful. 


.  LOCAL  REMOTE 


Figure  5.  Transfer  Sequential  File 
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Trans  fer  Program  File.  The  transferring  of  a  program 
file  is  handled  differently  than  a  sequential  file.  A 
program  file  is  relative  record,  or  random,  file.  A  program 
file  contains  several  executeable  object  code  programs.  The 
DFD  in  figure  6  shows  the  processes  required  to  transfer  a 
program  file.  The  program  file  is  converted  to  a  sequential 
file  prior  to  transmission  and  back  into  a  program  file  when 
it  arrives  at  its  destination.  The  formatting  prior  to 
transmission  simplifies  and  standadizes  the  file  format  that 
must  be  processed  by  the  lower  level  protocols. 


repeat 


Transfer  Message.  The  transfer  message  function  allows 
the  user  to  compose  and  transmit  messages  addressed  to  a 
peripheral  of  a  remote  computer.  The  function  also  allows 
the  user  to  abort  the  message  prior  to  transmission.  As 
shown  in  figures  7  and  8,  three  discrete  commands  are 
available  to  the  user.  The  compose  command  provides  the 
user  with  an  input/output  (I/O)  procedure  that  allows 
editing.  If  the  user  decides  not  to  send  a  message,  he  can 
use  the  abort  message  command.  If  the  user  decides  to  send 
the  message,  he  executes  the  send  message  command. 


Figure  7.  Compose  and  Abort  Message 
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Send  Message 
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Execute  Remote  Program .  This  R-S  function  requires 
relatively  few  processes  compared  to  the  other  functions 
described.  It  involves,  simply,  transmitting  a  command 
which  specifies  the  location,  name,  and  language  of  the 
program,  such  as  FORTRAN,  Pascal,  or  assembly.  The 
processes  associated  with  Execute  Remote  Program  are  shown 
in  figure  9. 


Figure  9.  Execute  Remote  Program 
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Execute  Remote  Progr  am  Development .  Program  development 
involves  several  major  tasks  including  editing,  compiling, 
link  editing,  and  testing.  To  accomplish  these  tasks 
effectively,  they  must  remain  discrete  functions.  Only  two 
of  the  functions,  compile  and  link  edit,  can  not  be 
initiated  by  commands  defined  previously.  Compiling  and 
link  editing  are  accomplished  by  the  Compile  and  Link  Edit 
commands,  respectively.  The  processes  initiated  by  the 
commands  are  shown  in  figure  10.  The  DFD's  are  deceptively 
simple.  Although,  Compile  and  Link  Edit  are  shown  as  single 
processes,  they  are  complex  processes  requiring  numerous 
parameters  in  addition  to  the  basic  command.  The  compile 
and  link  °dit  processes  must,  therefore,  monitor  the  message 
and  list  files,  respectively,  to  determine  the  progress  of 


the  requested  function.  Appropriate  status  messages  must  be 
returned  to  the  user. 


System  f?e£u  _i£  e  m  e  jn  t  s  Analyses  S  u  mma£Vf  .  The  systems 
requirements  analysis  provides  an  understand  i  ng  of  what  an 
R-S  link  must  do,  in  general,  and  the  processes  required  to 
accomplish  each  of  the  specific  functions.  From  the 
requirements  analysis  it  was  clear  that  there  were  two 
important  classes  of  processes.  First,  basic  data 
communications  processes  are  needed  to  facilitate  a  dialogue 
between  the  two  computers  being  served  by  the  R-S  network. 
Second,  the  R-S  processes  themselves  must  be  created,  or,  if 
the  R-S  processes  already  exist,  they  must  be  made 
accesssible  to  the  network.  The  following  section  evaluates 
existing  AWS  modules  to  determine  which  processes  identified 
in  the  analysis  currently  exist. 

Existing  flMS  Modules 

Several  existing  A**?  hardware  and  software  modules  were 
found  to  have  capabilities  that  satisfy  certain  system 
requirements.  Each  module  is  described  in  general  and  its 
role  in  satisfying  system  requirements  is  identified. 
?i£d.!Li::222  C  om£  u  t  e  r  .  The  Texas  Instruments  Model  990 
computer  is  based  on  the  TMS  9990  16  bit  microprocessor. 
The  hardware  is  designed  to  support  a  concept  called  the 
workspace.  The  workspace  is  a  16  word  block  of  memory 
associated  with  each  program.  Each  word  of  the  workspace  is 
rapidly  accessible  by  the  program  in  a  manner  normally 
associated  with  hardware  registers.  Consequently,  each  word 
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of  the  workspace  is  known  as  a  workspace  register  (WR)  Three 
hardware  registers  are  also  available;  the  workspace  pointer 
( WP ) ,  Program  Counter  (PC),  and  Status  Word  (ST).  The  WP 
points  to  the  first  word  of  the  programs  workspace.  The  PC 
and  ST  monitor  the  address  of  the  current  instruction  and 
the  program  status,  respectively.  When  a  context  change  is 
indicated,  such  as  with  a  hardware  interrupt  or  a  subroutine 
call,  the  old  WP,  PC,  and  ST  are  stored  in  WR ' s  13,1^,and15 
of  the  newly  executing  program’s  workspace.  The  storing  of 
the  old  pointers  in  the  workspace  registers  provides  an 
efficient  means  of  returning  to  the  interrupted  or  calling 
program.  The  overall  effect  of  the  above  features  of  the 
Model  990  is  rapid  and  efficient  handling  of  many  external 
interrupt  sources,  such  as  communications  links.  Therefore, 
the  hardware  architecture  of  the  Model  990  is  well  suited  to 
the  support  of  computer  communications,  either  as  a  host  or 
as  a  node. 

Peripherals .  The  peripherals  that  are  associated  with  the 
Model  990  computer  provide  I/O  and  storage  capabilities  for 
the  computer  and  the  R-S  link.  To  a  large  degree, 
peripherals  are  the  reason  that  resource  sharing  is 
desirable.  cor  instance,  the  SDMF  has  additional  memory 
that  allows  it  to  support  software  development  utilities 
that  the  typical  site  cannot  accomodate.  Sharing  the  SDMF, 
therefore,  benefits  the  entire  network  considerably. 
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Peripherals  that  are  currently  available  in  AMS  are  listed 
below : 

TI  810  Line  Printer 
50  MBYTE  Hard  Disk  Drive 
10  MBYTE  Hard  Disk  Drive 
Dual  Floppy  Disk  Drive 
TI  911  Vidio  Display  Terminal 
QUME  Letter  Quality  Printer 
Tektronics  Graphics  Display 

Communications  I nter  face  Card  .  The  Communications  Interface 
Card  is  an  optional  hardware  module  which  resides  in  the 
Model  990  chassis(Ref  18).  It  provides  an  RS-232  standard 
interface  to  a  data  modem  and  supports  snychronous  and 
asynchronous  data  communications.  In  conjunction  with  the 
modem,  and  telephone  circuit,  the  communications  interface 
card  implements  the  physical  level  protocols. 

V  ad  i  c  3*100  Data  Modem .  The  Vadic  3*100  Data  Modem  supports 
synchronous  and  asynchronous  data  communications  up  to  9600 
BPS.  The  data  modem  provides  the  interface  between  the 
Communications  Interface  Card  and  the  telephone  circuit. 
The  data  modem  contributes  to  the  implementation  of  the 
physical  level  protocols. 

C  ommu  n  j.  c  a  t  j.  o  n  s^  Module.  The  Communications  Module  is  a 
program  developed  by  the  Microbase  Co.  to  establish  a  data 
communications  connection  between  two  computers.  The 
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program  is  executed  by  a  special  operating  system  command. 
A  telephone  number  is  the  only  parameter  entered. 

3]_&0  •  The  Model  990  computer  3780  Emulator 
(Ref  20)  emulates  the  IBM  3780  Data  Communications 
Terminal.  In  other  words,  the  3780  Emulator  implements  the 
data  communications  protocols  of  the  IBM  3780.  The 
protocols  implemented  effectively  span  the  link  level  to  a 
minimal  R-S  capability.  The  link  level  consists  of  IBM's 
Binary  Synchronous  Communications  (BSC)  protocol.  The 
network  and  transport  layer  functions  are  not  evident  since 
the  Emulator  supports  a  simple  link  between  two  computers 
without  routing  or  multiplexing.  The  presentation  layer 
function  that  is  evident  in  the  Emulator  is  the  process  of 
transforming  the  TI  sequential  file  format  into  an  IBM 
sequential  file  format  and  vice  versa.  a  liaison,  or 
session,  is  established  between  the  two  computers  when  the 
Emulator  of  one  is  commanded  to  ANS  (answer)  and  the  other 
is  commanded  to  CALL.  The  Emulator  can  be  considered  to 
have  a  minimal  R-S  layer  since  it  is  capable  of  transferring 
sequential  files,  an  attribute  associated  with  the  R-S 
layer.  The  Emulator  can  also  execute  a  remote  program  if  it 
is  in  the  operating  system  program  file.  By  interfacing  to 
the  Emulator,  a  program  is  provided  with  all  of  the  data 
communications  functions  associated  with  a  minimal  R-S  level 
and  below.  The  Emulator  provides  all  the  basic  data 


communications  capabilities  needed  by  an  R-$  process. 

Operating  the  Emulator  involves  entering  commands  and 
monitoring  log  output.  Commands  may  be  entered  from  any  one 
of  three  sources;  a  terminal,  a  command  file,  or  an 
intertask  message  queue.  The  desired  mode  is  designated 
upon  activation.  Similarly,  the  log  output  may  go  to  one  of 
three  destinations;  a  terminal,  a  log  file,  or  an  intertask 
message  queue.  In  its  role  as  a  R-S  network  link  module, 
the  Emulator  interfaces  to  the  R-S  process  via  two  intertask 
message  queues. 

DX- 1 0  Operating  System .  The  operating  system  associated 
with  the  Model  990  computer  used  in  this  investigation  was 
the  DX- 1 0 ,  release  3-3,  operating  ?ystem(Ref  18).  It  is  an 
interactively  oriented  operating  system,  but  it  also 
supports  a  batch  mode  environment.  DX-10  is  a 
mu  1 1 i - 1 e rm  i  n al  system  capable  of  making  each  of  several 
users  appear  to  have  exclusive  control  of  the  system. 
Program  segmentation  is  supported  such  that  each  program  may 
have  up  to  one  task  and  two  procedure  segments.  If 
procedure  segments  are  reentrant,  or  pure,  they  can  be 
shared  with  other  tasks.  Each  terminal  can  have  two  tasks 
active  simultaneously;  a  foreground,  or  interactive,  task 
and  a  background,  or  non i n t e r ac t i v e  task.  Higher  order 
languages  supported  include  FORTRAN,  Cobol ,  RPGII,  Pascal, 
and  both  scientific  and  business  Basic.  A  text  editor,  link 


editor,  and  debugging  facility  are  included  with  the  program 
development  capabilities.  Other  utility  programs  include  a 
data  base  management  package  and  a  Sort/Merge  package. 

The  operating  system  proved  to  be  the  single  most 
important  asset  available  for  satisfying  the  R-S  link 
requirements.  Since  an  operating  system  is  the  controller 
of  each  computer's  resources,  the  only  way  to  access  those 
resources  is  through  the  operating  system.  Most  of  the 
resources  exist  external  to  the  operating  system,  with  the 
operating  system  controlling  access  to  them.  However,  the 
operating  system  may  also  be  the  direct  supplier  of  the 
resource.  Figure  11  shows  the  basic  relationship  of  the 


operating  system  to  the  other  R-S  link  resources. 


Operating  System  Interfaces 

Before  a  system  design  could  be  accomplished,  the 
interfaces  to  the  operating  system  had  to  be  understood. 
The  following  subsections  describe  those  interfaces. 
Operator/Operating  System .  The  operating  system  consists  of 
many  independent  tasks  which  are  controlled  by  a  supervisory 
task  called  the  System  Command  Interpreter  (SCI).  The  SCI 
is  primarily  intended  to  be  an  interactive  interface  that 
accepts  commands  from  an  operator.  However,  upon  receipt  of 
an  execute  batch  (XB)  command  from  the  operator,  a  copy  of 
SCI  is  executed  in  the  background  that  obtains  commands  from 


a  "batch  file"  designated  by  the  operator, 


Operating  System  relationships 


The  SCI  language  consists  of  primitives  and  commands. 
A  primitive  is  processed  directly  by  the  SCI  but  commands 
are  interpreted  by  SCI  by  reading  a  sequential  file  called  a 
Command  Procedure  (PROC)  which  can  contain  primitives  and 
commands.  Commands  can  be  nested  in  other  commands  as 
indicated  by  the  fact  that  a  PROC  may  contain  commands. 
Primitives  may  be  entered  directly  at  a  terminal,  but  they 
are  primarily  intended  for  use  in  PROCs.  A  primitive 
consists  of  a  period  followed  by  a  mnemonic.  The  primitive 
is  followed  by  mandatory  and  optional  parameters.  A  typical 
primitive  is  .BID  which  causes  a  task  to  be  executed  in  the 
foreground  mode.  A  typical  command  is  Execute  Task  (XT) 
which  is  similar  to  .BID  and,  in  fact,  contains  a  .BID.  The 
XT  command,  however,  is  operator  oriented  and  aids  the 
operator  by  prompting  for  parameters.  Primitives  such  as 
•IF,  .ELSE,  and  .ENDIF  exist,  allowing  program-like 
decisions  in  a  PROC. 

A  Command  Procedure  (PROC)  usually  causes  the  execution 
of  a  program  which  is  permanently  associated  with  a 
particular  command.  A  program  which  is  permanently 
associated  with  a  command  is  called  a  Command  Processor.  A 
Command  Processor  uses  special  operating  system  subroutines 
to  access  parameters  in  the  Terminal  Communications  Area 
(TCA).  The  TCA  is  a  special  portion  of  memory  associated 
with  each  interactive  terminal.  The  parameters  are  placed 
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in  the  TCA  by  SCI  as  it  interprets  the  command  PROC. 

In  summary,  the  Operator/Operating  System  interface 
provides  a  versatile,  uniform  interface  for  the  operator. 
The  SCI  is  commanded  by  a  simple,  operator  entered  mnemonic 
that  causes  the  SCI  to  prompt  the  operator  for  the  necessary 
parameters.  SCI  then  executes  the  appropriate  0/S  programs 
and  command  processors.  Commands  may  be  added  to  the  SCI 
repertoire  by  the  user.  R-S  Network  Commands  defined  by 
this  investigation  were  defined  as  SCI  commands.  The 
software  portion  of  the  R-S  process  developed  by  this 
investigation  acts  as  a  command  processor  and  is  executed  by 
each  of  the  network  commands. 

Applications  Program /Operating  System .  An  applications 
program  can  communicate  with  the  operating  system  with 
supervisory  calls  (SVC).  There  are  more  than  200  SVCs. 
Most  of  the  SVCs  are  included  in  three  classes;  file  and  I/O 
calls,  Program  Control  calls,  and  memory  control  calls. 
Supervisory  calls  are  provided  expressly  to  enable  an 
applications  program  to  command  the  operating  system.  For 
most  programs,  the  SVCs  provided  are  adequate.  However,  to 
satisfy  the  R-S  link  requirements  a  more  powerful  interface 
was  needed  in  addition  to  the  SVCs.  The  special  interface 
developed  by  this  investigation  is  described  under 
"Applications  Program/SCI". 

2££J2££££Z  A.££ii.£a  ti££S  £.££££££•  The  primary  means  of 
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implementing  communications  between  Ine  operator  and  an 
applications  program  is  by  including  I/O  supervisory  calls 
(SVC)  in  the  program  that  communicates  with  the  terminal. 
Additionally,  there  is  a  degree  of  communications  prior  to 
the  execution  of  the  program,  if  the  program  is  defined  as  a 
command  processor.  If  the  program  is  a  command  processor, 
the  operator  is  prompted  for  parameters  needed  by  the 
program  and  the  operator  entered  parameters  are  subsequently 
fetched  by  the  program  from  the  Terminal  Communications  Area 
(TCA ) . 

Applications  Program/Applications  Program .  An  application 
program  may  communicate  directly  with  another  applications 
program  by  using  the  Intertask  Communications  (ITC) 
supervisory  call.  The  ITC  SVC  provides  a  queue  into  which  a 
program  may  place  messages,  each  containing  up  to  92 
Characters.  The  queues  are  usually  established  with  a  1000 
character  capacity  at  system  generation,  but  they  can  be 
smaller  or  larger.  The  messages  may  be  fetched  by  another 
applications  program  on  a  first  in  first  out  (FIFO)  basis. 
Applications  Program /SCI .  The  SVCs  provide  an  adequate 
interface  to  the  operating  system  for  most  appl ications. 
However,  the  system  requirements  analysis  for  the  R-S  link 
revealed  several  basic  processes  which  were  contained  in  the 
0/S  but  were  not  accessible  with  SVCs.  The  required 
processes  could,  conceivably,  have  been  duplicated. 
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However,  the  processes  in  question  were  not  trivial,  making 
it  impractical  to  redevelop  them.  For  instance,  the  process 
to  transform  a  random  file  into  a  sequential  file  is  an 
inherent  capability  of  the  0/S.  Another  example  is  the 
process  of  compiling.  Obviously,  a  suitable  interface 
between  the  R-S  process  and  the  0/S  had  to  be  found  or 
developed . 

A  thorough  study  of  the  DX-10  Operating  System  Manual 
(Ref  18)  did  not  reveal  a  means  of  the  achieving  the  desired 
interface.  However,  an  operating  system  subroutine  was 
discovered  through  a  suppl emen tary  source  (Ref  5).  The 
subroutine  had  the  essential  capabilities  to  effect  the 
interface.  The  assembly  language  routine  found  is  named 
S$8 I DT .  It  was  designed  to  allow  an  applications  assembly 
language  routine  to  execute  a  program  that  fetches  its 
parameters  from  the  TCA.  The  applications  assembly  program 
calls  S$BIDT  and  passes  parameters  to  S$BIDT  according  to  a 
prescribed  format.  Subsequently,  S$BIDT  places  the 
parameters  in  the  TCA  and  executes  the  program  that  fetches 
the  parameters  from  the  TCA. 

The  operation  of  SSBIDT  is  important  because  many  0/S 
programs,  including  SCI,  use  the  TCA  to  acquire  their 
parameters.  Some  SCI  commands  result  in  the  SCI  executing 
other  independent  0/S  programs.  For  those  commands,  the  SCI 
could  be  emulated  by  executing  those  programs  through 


S$BIDT.  However,  that  does  not  result  in  a  good  general 
solution  to  the  interface  problem  because  many  SCI  commands 
result  in  SCI  calling  an  overlay  of  itself.  Since  there  is 
no  way  to  execute  an  overlay  independently  of  its  root  task, 
it  was  not  possible  to  emulate  the  SCI  for  all  commands. 
The  solution  lay  in  emulating  the  Execute  Batch  (XB)  command 
and  designating  a  batch  file  that  contained  the  desired 
commands . 

Fortunately,  the  XB  command  could  be  emulated  through 
the  use  of  S$BIDT.  The  XB  command  prompts  the  SCI  to  read  a 
PROC  which  contains  a  .QBID  primitive  which  instructs  the 
SCI  to  execute  a  specified  task  in  the  background  mode.  The 
XB  PROC  contains  the  .QBID  followed  by  three  parameters;  the 
task  ID  of  SCI,  a  batch  file  pathname,  and  a  batch  list 
pathname.  To  emulate  the  XB  command,  a  background  program 
must  execute  SSBIDT  and  pass  the  necessary  parameters. 
S$BIDT  places  the  two  file  parameters  in  the  TCA  and 
executes  a  background  copy  of  SCI.  Upon  execution,  SCI 
fetches  the  parameters  and  executes  the  primitives  and 
commands  in  the  designated  batch  file. 

Although  an  applications  program  could  emulate  the  SCI 
in  some  instances  by  executing  the  appropriate  0/S  routines 
with  the  S$BIDT  interface,  most  SCI  commands  involve  an 
overlay  of  the  SCI.  Therefore,  it  would  usually  be 
necessary  to  emulate  the  XB  command  by  executing  SCI  through 


S$BIDT.  As  a  result  of  these  considerations,  it  was  decided 
that  the  S$BIDT/SCI  interface  should  be  the  standard 
applications  program/operating  system  interface  when  an  SVC 
is  not  available.  This  simplifies  the  programming  of  the 
R-S  process  by  eliminating  the  possibility  of  interfacing 
with  many  0/ S  programs  with  varied  parameter  requirements. 
A  more  detailed  description  of  the  S$BIDT/SCI  interface  is 
contained  in  the  Appendix. 

System  Design 

This  section  describes  the  combining  of  new  and 
existing  modules  into  a  system  that  fulfills  the  system 
requirements.  The  existing  modules  described  in  the 
preceding  section  possess  most  of  the  basic  capabilities 
needed  to  satisfy  the  R-S  link  requirements.  However,  if 
the  modules  were  allowed  to  remain  as  independent  processes 
in  each  link  computer,  the  required  R-S  functions  could  be 
realized  only  by  having  an  operator  at  each  end  of  the 
link.  The  operators  would  have  to  communicate  via  telephone 
and  execute  numerous  commands  at  the  proper  times  to  achieve 
the  necessary  synchronism.  To  automate  the  functions,  a 
coordinating  process  is  required  at  each  end.  The 
coordinating  process  is  the  R-S  process  at  each  end  of  the 
link.  The  two  R-S  processes  effectively  combine  the  many 
processes  in  each  computer  into  two  cooperating  network 
processes.  The  interfaces  described  earlier  in  this  chapter 
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enable  the  R-S,  applications  process  to  accomplish  tnat 
goal . 

The  system  design  accomplished  by  this  investigation  is 
shown  in  figure  12.  The  R-S  process  has  been  divided  into 
two  processes,  a  foreground  executable  process  known  as 
Foreground  Network  (FORENET)  and  a  background  executable 
process  known  as  Background  Network  (BACK NET).  The  Data 
Communications  process  exists  as  two  processes,  the  3780 
Emulator  and  the  Microbase  Communications  program.  The 
peripherals  that  exist  at  each  end  of  the  link  are  also 
illustrated  and  the  operating  system  is  shown  connecting  all 
of  the  resources. 

The  operation  of  the  system  can  best  be  described  from 
the  perspective  of  the  R-S  processes,  FORENET  and  BACKNET. 
The  typical  R-S  function  is  performed  under  the  supervision 
of  two  R-S  processes,  a  local  FORENET  and  a  remote  BACKNET. 
FORENET  and  BACKNET  cooperate  to  accomplish  the  many 
functions  implied  by  the  R-S  command  entered  by  an  operator 
or  a  user  process.  Figure  13  is  a  simplified  view  of  the 
R-S  link  with  only  R-S  processes  and  the  command  sources 
visible.  The  data  communications  processes  are  transparent 
to  the  R-S  processes. 

The  execution  of  an  R-S  function  begins  when  an  R-S  SCI 
command  is  entered.  The  SCI  interprets  the  command  by 
reading  primitives  and  commands  in  the  PROC  associated  with 
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Figure  12.  System  Design 


FORENET  and  BACKNET  R-S  Processes 


the  command.  The  typical  PROC  will  cause  SCI  to  acquire 
parameters  associated  with  the  command  and  execute  the  local 
FORENET  in  the  foreground  mode.  The  first  action  FORE NET 
takes  is  to  check  if  the  local  BACK NET  is  active.  If  the 
local  BACKNET  is  active,  FORENET  informs  the  user  that  the 
link  is  busy.  Otherwise,  the  local  FORENET  executes  the 
remote  BACKNET  and  communicates  the  command  type.  The 
interchange  continues  between  FORENET  and  BACKNET  until  the 
R-S  function  is  completed. 

There  are  several  reasons  for  the  selection  of  the 
foreground  and  background  modes  associated  with  FORENET  and 
BACKNET,  respectively.  BACKNET  is  always  the  remote  process 
and  sometimes  the  local  process.  In  either  case,  BACKNET 
must  execute  SCI  in  the  batch  mode  through  the  S$BIDT/SCI 
interface.  Since  the  S$RIDT/SCI  interface  can  only  be  used 
by  a  process  in  the  background  mode,  BACKNET  must  always  be 
executed  in  the  background  mode.  Since  FORENET  is  intended 
to  be  an  interactive  process,  it  is  convenient  for  it  to  be 
in  the  foreground  node  where  0/S  interactive  features  are 
most  prevalent.  Additionally,  it  is  convenient  for  FORENET 
to  be  executed  in  the  foreground  so  that  it  can  be  active  at 
the  same  time  as  BACKNET.  Even  if  the  link  is  busy  because 
an  operator  at  the  other  end  has  activated  it,  the  local 
operator  will  be  able  to  initiate  a  command,  and  FORENET 
will  determine  that  the  link  is  busy  by  checking  the  status 


of  BACKNET  and  notify  the  operator  appropriately.  If  an 
attempt  was  made  to  execute  FORENET  in  the  backgound  mode  at 
the  same  time  as  BACKNET,  the  operator  would  receive  an 
ambiguous  0/S  error  that  an  unspecified  task  was  already 
active  in  the  background  mode. 

This  section  has  described  the  system  design  of  the  R-S 
link.  The  system  design  defines  the  relationships  of  the 
R-S  processes  to  the  existing  A  v  S  modules.  The  system 
requirements  are  satisfied  through  the  ability  of  the  R-S 
processes  to  interpret  R-S  network  commands  and  to 
coordinate  the  actions  of  several  independent,  subordinate 
modules.  The  apparent  affect  is  that  the  command  is 
performed  by  only  two  processes,  a  remote  and  a  local 
process . 

Network  Commands 

With  an  understanding  of  the  system  design  it  was 
possible  to  define  a  minimum  set  of  commands.  Yost  of  the 
commands  defined  were  directly  related  to  the  R-S  functions 
defined  in  the  system  requirements.  However,  others  were 
needed  for  initialization  and  control  purposes. 

Also,  a  batch  command  was  defined  to  allow  a  general 
method  of  accessing  remote  computer  resources.  It  is 
obviously  not  a  simple  or  highly  automated  command,  but  it 
does  provide  a  means  of  accessing  any  resource  of  a  remote 
computer  if  the  operator  is  skilled  in  the  SCI  language. 
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The  following  network  commands  were  defined. 


NI 

-- 

Network 

Initialize 

NLON 

-- 

Network 

Log  On 

NTF 

Metwor k 

transfer  file 

NMC 

Network 

Message  Compose 

NMS 

-- 

Network 

Message  Send 

NMA 

Network 

Message  Abort 

NTPF 

-- 

Network 

Transfer  Program  File 

NXT 

-- 

Network 

Execute  Task 

NCOMP 

— 

Network 

Compile 

NLINK 

— 

Network 

Link  Edit 

NXB 

-- 

Network 

Execute  Batch 

NLOFF 

-- 

Network 

Log  Off 

NQ 

— 

Network 

Quit 

The  set  of 

c  ommand  s 

represents  a  complete  set  in  the  sense 

that  they  result  in  all  of  the  required  R-S  functions  being 
performed . 

Summary 

This  chapter  has  analyzed  the  R-S  Network  Link  system 
requirements  and  described  a  system  design  that  satisfies 
those  requirements.  The  system  requirements  were  analyzed 
to  determine  the  processes  needed  to  satisfy  the 
requirements  and  Data  Flow  Diagrams  were  used  to  illustrate 
the  processes.  Existing  AMS  hardware  and  software  modules 
that  partially  satisfy  the  system  requirements  were 
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described.  A  system  design  was  described  that  consists  of 
existing  AMS  modules  and  the  newly  defined  R-S  processes. 
Based  on  the  system  design  and  the  system  requirements  a  set 
of  network  commands  were  defined.  The  next  chapter 
describes  the  analysis  of  the  R-S  network  commands  to 
determine  what  processes  must  be  implemented  in  the  R-S 
software  to  satisfy  the  software  requirements. 


III. 


Software  Requirements  Analysis 


This  chapter  describes  the  analysis  of  the 
Resource-Sharing  (R-S)  software  requirements.  The  analysis 
determines  the  processes  that  must  be  implemented  in  the  R-S 
software  by  analyzing  what  the  software  must  do  in  response 
to  the  network  commands.  Data  flow  diagrams  are  shown  for 
each  command  to  illustrate  the  processes  and  data  needed  for 
the  command.  The  processes  are  grouped  as  they  would  be 
geographically  to  enhance  visualization  of  the  protocols 
described  for  each  command. 

General  I n  forma  t ion 

There  are  several  features  that  appear  in  all  or  most 
of  the  network  command  data  flow  diagrams  (DFP).  The 
features  include  conventions  of  notation,  methods  of  passing 
command  parameters  across  the  R-S  link,  and  communications 
techniques  between  R-S  processes  at  opposite  ends  of  the 
link. 

As  shown  in  figure  12,  Chapter  2,  the  major  processes 
at  each  end  of  the  link  include  two  R-S  processes,  the  3780 
Emulator,  and  the  operating  system.  The  only  operating 
system  process  to  appear  in  the  command  analyses  was  the 
System  Command  Interpreter  (SCI).  To  differentiate  between 
local  and  remote  processes,  the  process  abbreviation  is 
suffixed  with  a  1  or  a  2.  Therefore,  the  local  processes  are 
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FORENET  1  ( F N 1 ) ,  BACKNET  1  ( BN  1  ) ,  3780  Emulator  1  (EMI),  and 
System  Command  Interpreter  1  (SCI1).  Similarly,  the  remote 
processes  are  identified  by  FN2,  BN2,  EM2,  and  SCI2. 
Standard  SCI  commands  are  referred  to  as  SCI  commands,  but 
network  commands  which  are  also  implemented  as  SCI  commands 
are  referred  to  as  network  commands. 

Figure  14  shows  the  configuration  of  processes  for 
typical  network  command.  The  circle  representing  each 
process  is  identified  by  the  process  name  and  the 
abbreviation  of  the  parent  process.  There  two  differently 
shaped  arrows  indicating  connectivity  between  R-S  processes 
and  the  log  and  command  ports  of  the  data  communi  'tions 
(Emulator)  processes.  The  "filled"  arrows  design  e  the 
common  connection  points  for  arrows  of  like  shaj.  Each  DFD 
illustrates  the  SCI  interface  to  an  operator.  The 
applications  process  interface  to  R-S  processes  is  oescribed 
separately  at  the  end  of  this  section. 

The  first  active  process  is  SCI1  Interpret  Command. 
SCI  interprets  a  network  command  by  reading  the  Command 
Procedure  (PROC)  associated  with  the  command.  The  PROC 
contains  SCI  commands  and  primitives  that  instruct  the  SCI 
to  prompt  the  operator  for  network  command  related 
parameters  (PARMS),  to  place  those  parameters  in  the 
Terminal  Communications  Area  (TCA),  and  to  execute  FN 1  . 

Upon  execution,  FN1  indirectly  executes  RN2  by 
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commanding  the  Emulator  with  a  S*$BID*<  >  Emulator  command. 
The  S*$BID*<  >  command  causes  the  execution  of  a  remote  task 
that  has  been  installed  on  the  S$PR0GA  system  program  file 
of  the  remote  Model  990  computer.  The  angle  brackets 
represent  required  and  optional  parameters  that  accompany  an 
actual  command.  Typical  parameters  include  the  name  of  the 
remote  task  and  a  32  bit  "code"  word.  In  the  analysis  of 
the  network  commands  the  code  word  is  used  to  transfer  a 
network  command  mnemonic.  A  detailed  description  of  the 
3780  Emulator  commands  is  contained  in  Ref  20. 

Once  a  complementary  pair  of  R-S  processes  have  been 
executed,  they  communicate  by  using  the  Protocol  1  and 
Protocol  2  files.  For  example,  after  the  BN2  Interpret 
Command  process  has  been  activated,  it  acknowledges 
activation  and  recognition  of  the  network  command  by  sending 
a  predetermined  message  in  the  Protocol  2  file.  Upon 
receipt  of  the  acknowledgement,  the  FN1  Interpret  Command 
process  passes  the  command  parameters  to  BN2  with  the  PARMS 
file.  The  PARMS  file  is  a  special  file  used  only  for  the 
transfer  of  command  parameters. 

The  BN2  Interpret  Command  Process  decides  which  network 
command  process  is  to  be  activated  by  examining  the  network 
command  and  its  parameters.  There  is  at  least  one  unique 
process  associated  with  each  command.  When  BN2  Interpret 
Command  process  decides  which  command  process  to  activate, 
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the  command  parameters  are  passed  to  that  process.  The 
transfer  of  parameters  also  implies  transfer  of  control. 

Upon  activation  by  the  BN2  Interpret  Command  process, 
the  network  command  processor  establishes  communications 
with  the  FN1  network  command  processor  by  exchanging 
protocol  messages  via  the  Protocol  1  and  Protocol  2  files. 
A  process  transfers  a  file,  such  as  Protocol  2,  by  placing  a 
command  in  the  Emulator  Command  Queue  of  the  form  S*<  >.  The 
source  and  destination  file  pathnames  replace  the  angle 
brackets  in  the  actual  command.  A  process  detects  the 
arrival  of  a  file,  such  as  Protocol  2,  by  reading  the 
Emulator  Log  Queue  messages.  An  Emulator  Receive  Pathname 
(RPN)  message  in  the  log  Queue  signals  the  arrival  of  a 
specific  file.  The  Emulator  Log  Queue  can  also  contain 
other  status  and  error  messages. 

The  network  command  processes  also  maintain 
communications  with  their  complementary  processes  at  the 
opposite  end  of  the  link  via  the  Protocol  1  and  Protocol  2 
files.  The  command  processes  must  communicate  frequently  to 
synchronize  their  activities.  The  local  command  processes 
send  status  and  error  messages  to  the  operator  or  user 
process,  and  all  command  processes  write  messages  to  the 
Network  Log  file.  Additionally,  most  command  processes  read 
and  write  to  other  files  to  accomplish  the  specific 
objectives  of  a  network  command.  Finally,  the  command 
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processes  must  exchange  protocol  messages  to  determine  if 
all  objectives  of  a  network  command  have  been  achieved  and 
terminate  themselves. 

A  network  user  process  can  command  the  R-S  processes  by 
interfacing  with  FN1  through  the  S$BIDT  operating  system 
routine  as  described  in  the  previous  chapter.  Figure  15 
shows  the  processes  that  facilitate  the  interface.  From  the 
perspective  of  the  Interpret  Command  process,  the  interface 
is  identical  to  the  SCI1  interface  because  S$BIDT  is  capable 
of  performing  all  of  the  functions  that  SCI1  was  commanded 
to  perform  by  the  PROC.  Specifically,  S$BIDT  places  the 
parameters  in  the  TCA,  executes  FN 1 ,  and  passes  the  command 
mnemonic  to  FN1.  Conversely,  the  PROC  used  to  facilitate 
the  operator  interface  must  only  contain  the  SCI  commands 
required  to  acquire  parameters  and  execute  FN1 ,  if  the 
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command  is  intended  to  be  executable  ty  a  user  process 
also.  The  reason  for  the  limitation  on  PROf  commands  is 
that  a  foreground  process  cannot  emulate  the  Execute  Batch 
(XB)  SCI  command.  XB  can  only  be  emulated  by  a  background 
process  as  described  in  the  previous  chapter. 

The  typical  command  described  in  this  section  is 
applicable  to  all  of  the  network  commands  except  Network 
Initialize  (NI),  Network  Quit  (NQ),  and  Network  Transfer 
Program  File  (NTPF).  NI  and  NQ  involve  local  processes  only 
and,  therefore,  does  not  require  a  liaison  between  processes 
across  the  link  as  described  above.  NTPF  is  also  an 
exception  because  both  the  local  and  remote  R-S  processes 
need  access  to  the  SCI  through  the  S$BIDT/SCI  interface. 
The  result  is  a  more  complicated  initialization  procedure  to 
establish  a  liaison  between  both  the  local  and  remote 
BACKNET  processes.  A  description  of  each  network  command 
analysis  is  contained  in  the  following  sections. 

Network  Initialize  (MI) 

Network  Initialize  (NI)  executes  and  initializes  the 
3780  Emulator,  enabling  the  local  AMS  site  to  receive  calls 
from  a  remote  site.  The  processes  necessary  to  realize  the 
NI  network  command  are  shown  in  figure  16. 

The  first  active  process  is  SCI1  Interpret  Command. 
SCI  interprets  the  NI  command  by  reading  the  NI  PROC.  The 
first  action  of  SCI  would  normally  be  to  acquire  parameters, 
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Figure  16.  Network  Initialize  (NI) 
but  NI  does  not  require  any  parameters.  The  first  SCI 
command  in  the  PROC  is  X  378u  which  needs  two  parameters 
which  are  the  same  each  time  NI  is  executed.  The  X3730 
command  and  its  two  parameters  result  in  the  execution  of 
the  Emulator  and  initialization  of  the  Emulators  command  and 
log  modes.  To  enable  the  Emulator  to  receive  commands  for 
applications  processes  such  as  FORE  NET  and  BACKNET,  the 
Emulator  must  be  initialized  to  receive  commands  from  an 
Intertask  Message  Queue.  To  further  satisfy  the  Emulator 
initialization  requirements,  the  Network  Log  file  is 
specified  as  the  Emulator  log  message  destination.  However, 
each  time  either  FORENET  or  BACKNET  are  activated,  the 
Emulator  is  commanded  to  place  log  messages  in  specified 
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Intertask  Message  Queue  (IMQ).  The  last  command  in  the  PROC 
is  a  .BID  primitive  that  executes  FN1. 

FN 1  Interpret  Command  activates  the  Initialize  Emulator 
process.  Initialize  Emulator  places  an  Emulator  AN3 
(answer)  command  in  the  Emulator  command  IMQ.  After 
receiving  verification  from  the  log  queue  that  the  Emulator 
is  in  the  answer  mode,  Initialize  Emulator  logs  the  status 
of  its  activity  in  the  Network  Log,  send  a  status  message  to 
the  user,  and  terminates.  The  Emulator  remains  active  and 
in  the  answer  mode  indefinitely. 

Network  Log  On  (NLON ) 

The  primary  objective  of  the  Network  Log  On  (NLON) 
command  is  to  establish  communications  between  the  Emulators 
of  two  sites.  NLON  also  logs  the  identity  of  the  user  and 
the  time  the  communications  session  began  in  the  Network  Log 
file  at  each  site.  Figure  17  shows  the  processes  needed  to 
realize  the  NLON  command. 

The  SCI1  Interpret  Command  process  acquires  the 
necessary  parameters  and  executes  the  Microbase 
Communications  (COMM)  program.  The  COMM  program  establishes 
the  physical  and  electrical  connection  between  the  Emulators 
of  the  sites  designated  by  the  user  parameters.  After  the 
COMM  program  terminates,  SCI1  executes  FN1. 

F N  1  begins  the  procedure  of  establishing  a  liaison 
between  the  R-S  processes  of  the  two  sites  by  executing 
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NLON ) 


BN2. 


F  N  1  executes  Pit?  via  the  Emulator  with  a  S*$9ID*NL0N 


Emulator  command.  BN2  acknowledges  the  receipt  of  a  NLON 
command  and  FN1  continues  the  dialogue  by  transferring  the 
PARMS  file.  The  last  action  of  the  complementary  Interpret 
Command  processes  is  to  pass  parameters,  and  thereby 
control,  to  their  respective  Log  On  processes. 

The  Log  On  processes  establish  communications  via  the 
Protocol  1  and  Protocol  2  files.  Having  established 
communications,  they  log  the  necessary  information  in  their 
Network  Log  files.  The  local  Log  On  processes  sends  a 
status  message  to  the  user  and  waits  for  a  completion 
message  from  the  remote  Log  On  process.  After  receiving  the 
completion  message,  the  local  Log  On  process  returns  a 

completion  message.  Finally,  both  processes  terminate.  The 

0 

Emulators  remain  active  and  connected,  waiting  to  provide 
communications  associated  with  another  network  command. 
Network  Transfer  File  (NTF) 

The  Network  Transfer  File  Command  causes  a  specified 
sequential  file  to  be  transferred  from  the  local  site  to  the 
remote  site,  or  vice  versa.  The  specified  file  may  be  any 
sequential  file  of  either  computer.  The  processes  necessary 
to  realize  the  NTF  command  are  shown  in  figure  18. 

The  execution  of  NTF  begins  with  the  usual  preliminary 
actions  by  the  Interpret  Command  processes  of  SC I  1 ,  FN 1 ,  and 
BN2.  SCI  acquires  parameters,  executes  FN1  and  passes 
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parameters  to  FN1.  FN1  executes  BN2  and  passes  parameters 
to  BN2. 

The  unique  actions  associated  with  the  execution  of  NTF 
begin  with  the  passing  of  control  from  FN1  and  BN2  to  one  of 
two  R-S  process  pairs.  If  the  NTF  command  has  specified 
that  a  local  file  be  transferred  to  the  remote  end,  FN 1 
passes  NTF  parameters  to  the  process  Send  Sequential  File 
and  BN2  passes  NTF  parameters  to  the  process  Receive 
Sequential  File.  If  a  remote  file  has  been  specified  for 
transfer  to  the  local  end,  parameters  are  passed  to  the 
Receive  Sequential  File  and  Send  Sequential  File  processes 
at  the  local  and  remote  ends,  respectively. 

If  the  sequential  file  is  being  transferred  between 
local  and  remote  ends,  the  transactions  between  Send 
Sequential  File  1  ( S S F 1  )  and  Receive  Sequential  File  2 
(RSF2)  proceed  as  follows.  SSF 1  commands  the  Emulator  with 
a  S  *  <  >  command  designating  the  file  to  be  transferred. 
RSF2  waits  for  a  message  from  the  Log  Queue  indicating  that 
a  file  with  the  specified  destination  pathname  has  been 
received.  During  the  course  of  these  tranactions  the 
processes  at  each  end  make  entries  in  the  Network  Log  file. 
As  a  minimum,  the  source  and  destination  pathnames  are 
logged.  Any  errors  reported  by  the  Emulator  are  also 
logged.  If  SSF1  receives  an  acknowledgement  of  receipt  from 
RSF2  or  detects  an  error  from  the  Emulator.  SSF  1  sends  a 


termination  message  to  RSF2  and  a  status  message  to  the 
user,  and  terminates. 

If  the  transfer  is  specified  to  be  from  the  remote  to 
the  local  end,  the  local  Receive  Sequential  File  and  remote 
Tramsmit  Sequential  File  processes  are  activated.  The 
transactions  between  the  processes  are  the  same  as  those 
described  above,  with  the  exception  that  the  Receive 
Sequential  File  process  sends  status  to  the  user  instead  of 
the  Transmit  Sequential  File  process. 

Network  Message  Commands 

The  network  message  commands  provide  the  operator  with 
the  capability  of  composing  a  message  and,  subsequently, 
either  sending  or  aborting  the  message.  The  Three  message 
commands  are  Network  Message  Compose  (NMC),  Network  Message 
Send  (NMS),  and  Network  Message  Abort  (NMA).  The  network 
message  commands  are  entered  by  an  operator  only.  The  NTF 
command  invokes  an  applications  process  with  the  capability 
to  send  a  message  to  a  remote  applications  process.  The 
DFDs  for  the  network  message  commands  are  shown  in  figure 
19. 

Ne twor k  Message  Compose  ( N  M Cl.  The  NMC  command  prompts 
the  operator  for  the  message  destination  and  causes  SCI1  to 
enter  the  editor  mode.  Roth  of  these  NMC  actions  can  be 
accomplished  with  SCI  commands  in  the  NMC  PROC.  The 
acquired  parameters  are  equated  to  operating  system  synonyms 
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for  future  use  with  the  other  message  commands.  After 
composing  the  message,  the  operator  strikes  the  terminal  CMD 
key  which  allows  him  to  enter  one  of  two  other  network 
message  commands. 

Network  Message  Send  _(_N_M  S_)  .  The  NMS  command  creates 
the  message  file  from  the  editor  file  and  transfers  the 
Message  file  to  the  message  destination.  As  with  the  NMC 
command,  the  NM'5  command  can  be  accomplished  without  unique 
R-S  processes.  However,  one  of  the  commands  needed  in  the 
NMS  PROC  is  the  network  command  NTF.  The  PROC  must  contain 
the  Quit  Editor  (QE)  command  which  creates  the  message  file 
from  the  Editor  file  and  the  NTF  command  which  transfers  the 
Message  file  to  the  message  destination.  The  parameters 
needed  with  NTF  are  supplied  by  the  synonyms  set  by  the  NMC 
command . 

Network  Message  Abort  (NMA )  .  The  MM A  command  discards 
the  editor  file  if  the  operator  decides  not  to  send  the 
message.  Again  all  of  the  NMA  functions  can  be  accomplished 
with  SCI  commands  and  primitives  in  a  PROC.  The  Quit  Editor 
and  Abort  (QEA)  command  discards  the  Editor  file.  A  status 
message  can  be  sent  to  the  Network  Log  file  with  a  .DATA 
primitive. 

Network  Transfer  Program  File  (NTPF ) 

The  NTPF  command  results  in  program  files  being 
transferred  from  one  site  to  another.  In  the  DX-10 


63 


operating  system,  a  program  file  is  a  relative  record  file 
that  contains  several  executable,  object  code  programs.  The 
file  contains  an  internal  directory  that  enables  direct 
access  to  individual  file  records.  A  program  file  is  also 
catagorized  as  a  file  directory  in  DX-10. 

Before  a  program  file  can  be  transferred  via  the  3780 
Emulators,  the  program  file  must  be  transformed  into  a 
sequential  file.  The  DX-10  operating  system  accomplishes 
this  transformation  when  commanded  with  a  Backup  Directory 
(BD)  command.  Conversely,  when  the  sequential  file  arrives 
at  the  destination  site,  the  sequential  file  must  be 
transformed  into  a  program  file  with  a  Restore  Directory 
(RD)  command. 

Since  the  R-S  processes  at  both  ends  of  the  link  must 
be  able  to  command  the  SCI,  both  background  processes, 
BACKNET1  and  BACKNET2,  will  have  to  participate  in  the 
execution  of  NTPF.  .The  processes  needed  to  realize  the  NTPF 
command  are  shown  in  figure  20. 

To  establish  a  liaison  between  BN1  and  BN2  requires  a 
more  complicated  initialization  procedure  than  for  the 
typical  command.  The  FN1  Interpret  Command  process  executes 
the  BN2  process,  and  the  BN2  process,  in  turn,  executes  the 
BN1  process.  Once  both  BN1  and  BN2  are  activated,  the 
initialization  procedure  between  them  is  the  same  as  between 
FN1  and  BN2  in  the  typical  command. 
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Figure  20.  Network  Transfer  Program  File  (NTPF) 


The  Interpret  Command  processes  of  BN1  and  BN2  must 
decide,  based  on  the  command  parameters  they  both  possess, 
which  program  file  processes  must  be  activated.  If  the 
program  file  is  being  transferred  from  the  local  end  to  the 
remote  end  of  the  link,  the  BN1  Send  Program  File  and  BN2 
Receive  Program  File  processes  are  activated.  If  the 
transfer  is  from  the  remote  to  the  local  end  the  processes 
are  reversed.  Once  activated,  the  Program  File  processes 
establish  communications  and  proceed  to  execute  the 
necessary  NTPF  functions. 

The  Send  Program  File  process  must  convert  the  program 
file  to  a  sequential  file  before  can  be  transferred  to  the 
other  site.  To  effect  the  conversion,  the  Send  Program  File 
process  executes  a  BD  SCI  command  by  constructing  a  BD  Batch 
file  and  executing  SCI.  The  BD  Batch  file  contains  a  BD 
command  and  its  associated  parameters.  The  Send  Program 
File  process  is  expanded  in  figure  21  to  illustrate  the 
interface  to  SCI  through  S$BIDT.  When  SCI  finishes  its 
execution  of  the  3D  Batch  file,  Send  Program  File  checks  the 
value  of  the  $$CC  system  synonym  to  see  if  SCI  has  returned 
an  error.  If  there  is  an  error,  the  user  is  notified  with  a 
status  message  and  the  BN  processes  terminate.  If  there  is 
no  error,  the  Program  File  processes  at  each  end  of  the  link 
pass  parameters  to  the  Sequential  File  processes.  The  Send 
and  Receive  Sequential  File  processes  cooperate  as  described 
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for  the  NTF  command  to  transfer  the  sequential  file  across 
the  link. 

When  the  sequential  file  arrives  at  the  opposite  end  of 
the  link,  it  must  be  converted  to  a  program  file.  The 
receive  Program  File  process  accomplishes  the  conversion  by 
constructing  a  RD  Batch  file  and  executing  SCI.  An  expanded 
view  of  the  receive  Program  file  process  is  shown  in  Figure 
22. 

Finally,  the  Program  File  processes  make  Network  Log 
entries,  send  a  status  message  to  the  user,  and  terminate. 


Figure  22.  Receive  Program  File 
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Network  Execute  Task  ( N X T  ) 

The  Network  Execute  Task  (NXT)  command  allows  a  user  to 
execute  any  remote  program  on  a  remote  site.  NXT  provides  a 
much  more  general  capability  than  does  the  Emulator.  The 
3780  Emulator  can  execute  a  remote  task  only  if  it  is 
installed  on  the  SSPROGA  system  program  file.  The  S$PR0GA 
program  file  is  intended  primarily  for  0/S  programs,  but  it 
is  sometimes  justified  to  install  an  applications  program  in 
S  $P  R  OG A  .  FORENET  and  BACKNET  must  be  installed  on  S$PR0GA 
so  that  they  can  be  executed  with  the  Emulator  bid  task 
capability . 

Figure  23  shows  the  NXT  command  processes.  The 
initialization  procedures  end  with  the  establishment  of 
communications  between  the  Execute  Task  processes  of  FN1  and 
B N 2 .  The  BN2  Execute  Task  process  executes  the  specified 
task  by  constucting  a  NXT  Batch  file  and  executing  SCI.  BN2 
Execute  Task  also  checks  the  status  of  the  executed  task  by 
periodically  executing  a  Check  Status  of  Tasks  (STS)  command 
through  the  S$BIDT  interface.  When  the  executed  task  has 
terminated,  3N2  Execute  "  •  sk  sends  a  completion  message  to 
FN1  and  both  R-S  proc.  "e.,  "‘rminate. 
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Figure  23.  Network  Execu 


N  etwork  Compile  ( N C 0 M P  ) 

The  NCOMP  command  give  the  user  the  capability  to 
compile  a  source  program  at  a  remote  site.  If  the  sr urce 
program  originated  at  the  local  end  of  the  link,  it  must 
first  be  transferred  to  the  remote  end  with  a  NTF  command. 
Similarly,  if  the  object  file  resulting  from  the  execution 
of  NCOMP  is  to  be  executed  at  the  local  end,  it  must  be 
transferred  with  the  NTF  command.  The  processes  associated 
with  NCOMP  are  illustrated  in  figure  24. 

After  the  liaison  between  FN1  Compile  and  BN2  Compile 
is  established,  the  Compile  process  constructs  a  NCOMP  Batch 
file  with  the  parameters  which  were  acquired  at  the  local 
end.  Compile  then  executes  SCI,  specifying  the  NC0MP  Batch 
file  as  the  command  source.  Compile  determines  the  status 
of  the  compile  by  reading  the  Compile  Message  file  and 
reports  status  periodically  to  the  user.  When  the  compile 
is  complete,  the  R-S  processes  terminate  in  their  normal 
manner.  The  various  files  indicated  in  the  DFD  are 
available  for  subsequent  network  operations. 


Network  Compile  (NCOMP) 


N  etwork  Link  Edit  ( N  L I N K  ) 

The  NLINK  command  provides  a  remote  link  editing 
capability.  The  object  files  to  be  linked  and  the  Link 
Control  file  must  be  resident  at  the  remote  site  at  the  time 
the  NLINK  command  is  executed.  The  Link  Control  file 
contains  commands  that  explicitly  identify  object  files  to 
be  linked.  The  Link  Control  file  also  contains  commands 
that  identify  libraries  to  ne  searched  for  object  files 
referenced  but  not  explicitly  identified.  The  processes 
associated  with  NLINK  are  shown  in  figure  25. 

The  NLINK  initialization  procedure  establishes  a 
liaison  between  the  FN1  and  P N 2  Link  Edit  processes.  The 
BN2  Link  Edit  process  constructs  a  NLINK  Patch  file  that 
contains  an  Execute  Link  Edit  (XLE)  command  and  designates 
the  relevant  input  and  output  files.  P  N  2  Link  Edit  monitors 
the  progress  of  the  link  edit  by  reading  the  Link  Listing 
file.  When  the  link  edit  is  complete,  DN2  Link  Edit  sends  a 
status  message  to  the  user  and  the  R-S  processes  terminate. 
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Network  Execute  Patch  (NXB) 

1 

The  NXB  command  results  in  a  user  specified  batch  file 
being  executed  at  the  remote  site.  NXB  provides  a  general 
access  capability  to  the  resources  of  the  remote  site.  NXB 
is  the  least  automated  of  the  network  commands.  To  use  the 
NXB  command  effectively,  the  operator  must  be  proficient  in 
the  SCI  language.  The  operator  composes  a  batch  file  at  the 
local  site,  transfers  it  to  the  remote  site  with  the  NTF 
command,  and  executes  it  with  the  NXB  command.  The 
processes  needed  for  NXB  are  shown  in  figure  26. 

I  After  initialization  of  the  FN1  and  BN 2,  BN 2  Execute 

Batch  executes  SCI2  through  the  S$BIDT  interface, 
designating  the  special  batch  file  as  the  command  source. 
BN2  Execute  Batch  checks  the  status  of  the  batch  execution 
by  periodically  executing  a  STS  command  and  reading  the  STS 
file.  When  the  batch  execution  is  complete,  the  user  is 
informed  and  FM1  and  PN2  terminate. 
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Network  Execute  Batch  ( NXB) 


Network  Log  Off  (NLOFF ) 

The  NLOFF  command  terminates  the  communications  session 
between  two  sites  by  terminating  communications  between  the 
Emulators  and  commanding  the  Emulators  to  the  answer  mode. 
The  NLOFF  command  uses  the  parmeters  acquired  by  the  NLON 
command.  The  processes  associated  with  the  NLOFF  command 
are  shown  in  figure  27. 

After  a  liaison  is  established  between  the  Log  Off 
processes,  both  processes  make  Network  Log  entries  with  the 
user  information  acquired  by  the  NLON  command.  Next,  FN 1 
Log  Off  commands  its  Emulator  to  terminate  with  an  emulator 
TERM  command.  Finally,  both  Log  Off  processes  reactivate 
their  Emulators,  command  the  Emulators  to  the  answer  mode, 
and  terminate  themselves. 


Network  Quit  (NQ ) 

The  NQ  command  terminates  the  site's  Emulator,  ending 
the  site's  participation  in  the  network.  The  processes 
needed  for  NQ  are  shown  in  figure  28.  The  Net  Quit  process 
logs  the  transaction  in  the  Net  Log,  and  terminates  the 
Emulator  with  a  TERM  command. 
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Summary 


This  chapter  has  described  the  analysis  of  the  thirteen 
R-S  network  commands.  The  analysis  determined  the  processes 
that  must  be  implemented  with  R-S  software.  The  processes 
needed  to  realize  each  command  were  shown  in  separate  data 
flow  diagrams  for  each  command.  The  processes  were  grouped 
in  the  data  flow  diagrams  as  they  would  be  geographically, 
enhancing  the  visualization  of  the  protocols  described  for 
each  command.  The  next  chapter  describes  the  software 
design  procedure  of  allocating  to  software  modules  the 
software  functions  defined  in  the  analysis. 
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IV. 


Network  Software  Design 


This  chapter  describes  the  design  of  the  network 
software.  The  purpose  of  the  design  process  was  to  arrive 
at  an  architecture  for  the  software  (Ref  11).  The  functions 
identified  in  the  software  requirements  analysis  process 
were  allocated  to  software  modules  during  the  design 
process.  The  design  assumed  that  the  software  would  be 
implemented  in  the  Pascal  language,  as  dictated  by  the 
system  requirements. 

Structured  Design 

The  structured  design  methodology  was  used  to  design 
the  network  software.  The  structured  design  process 
transforms  data  flow  diagrams  into  a  hierarchy  of  modules 
represented  by  structure  charts  (Ref  11).  Structured  design 
was  chosen  because  the  resulting  structure  charts 
communicate  the  design  effectively. 

Figure  29  illustrates  an  example  of  a  simple  structure 
chart.  A  box  represents  a  software  module  that  either 
transforms  or  processes  data.  A  box  with  two  vertical, 
interior  lines  represents  an  existing  software  module.  The 
arrows  connecting  the  modules  represent  calls  to  a 
subordinate  module  and  the  arrows  beside  the  connecting 
arrows  represent  the  transfer  of  data,  control,  or  both. 
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Figure  2 9.  Structure  Chart 


8 


The  open  circle  represents  existing  operating  system 
functions . 

The  basic  structure  illustrated  in  the  figure  is  known 
as  a  s ou r c e/ t r an s fo rm/ s i nk  structure.  Data  is  acquired 
through  the  left,  or  afferent,  branch;  transformed  in 
middle,  or  transform,  branch;  and  outputted  through  the 
right,  or  efferent,  branch.  The  goal  of  structured  design 
is  to  achieve  a  design  that  is  readily  understood.  A  design 
structure  that  reflects  the  problem  it  solves  enhances 
understanding  of  the  design  (Ref  11:6ft).  Therefore,  if  the 
basic  nature  of  a  problem  is  to  input,  process,  and  output 
data,  then  the  source/transform/sink  structure  enhances 
understanding  of  the  design  by  segregating  the  input/output 
functions  from  the  primary  functions  of  the  program. 
Furthermore,  the  modules  should  be  defined  such  that  they 
implement  one  function  that  can  be  described  by  a  verb-noun 
phrase,  again  enhancing  unders tand ing  of  the  design. 

Overview 

Two  software  programs  were  designed  as  part  of  this 
investigation.  The  programs  represent  the  static, 
instruction  portion  of  the  FORENET  and  BACK NET  processes 
shown  in  figure  12,  Chapter  2.  Roth  programs  reside  in  each 
AMS  site,  providing  each  site  with  the  capability  to 
participate  in  the  execution  of  a  network  command.  The 
structure  charts  that  illustrate  the  design  structure  of 
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FORENET  and  BACKNET  are  shown  in  figures  39  and  31, 
respectively . 

When  one  of  the  network  programs  is  executed,  its  first 
actions  involve  the  acquisition  of  a  command  and  its 
parameters.  Based  on  these  inputs,  the  Initialize  Link 
module  can  initialize  the  network  as  required  for  the 
particular  network  command.  The  Initialize  Link  module  is 
an  example  of  a  transform  module  as  defined  in  the  previous 
section.  By  processing  the  input  data,  Initialize  Link 
determines  whether  the  Execute  BN1  and  Send  Parms  modules 
should  he  called  to  establish  a  link  with  another  site.  If 
a  distant  program  is  executed,  Initialize  Link  must  also 
decide  which  data  is  tc  be  passed  to  the  program.  Once  the 
link  is  initialized  for  a  particular  network  command,  one  of 
the  remaining  10  transform  modules  are  selected  to  perform 
the  desired  resource- sharing  network  functions. 

After  a  resource-sharing  module  is  called  and 
parameters  have  been  passed  to  the  module,  the  module 
retains  control  until  all  network  command  functions  have 
been  accomplished.  Mo  additional  data  tranactions  are 
handled  by  the  apparent  afferent  and  efferent  branches. 
This  structure  may  at  first  sight  appear  to  violate  the 
goals  of  structured  design  and,  in  particular,  the 
s o u r c e / t r a n s f o r m / s  i  n k  structure.  However,  the  design 
structure  does  support  the  stated  goal  of  reflecting  the 
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FORFNFT  Structure  Chart 


RACKNFT  Structure  Chart 


nature  of  the  problem.  A  resource-shar in?,  (R-S)  module  is 
called  to  accomplish  a  particular  R-S  function  and  most  R-S 
functions  inherently  require  communications  ( i n put/ ou t put )  . 
Therefore,  the  R-S  modules  are  provided  with  direct  control 
over  the  communications  resources  needed  to  accomplish  their 
functions.  When  a  module  has  completed  its  assigned 
function,  control  returns  to  the  main  module  and  the  program 
terminates . 

0/ S  Interface  Procedures 

Most  of  the  network  software  modules  must  interface 
with  the  DX-10  operating  system.  The  interfaces  are 
implemented  with  various  Pascal  procedures.  Most  of  the 
procedures  are  DX-10  operating  system  dependent,  external 
Pascal  procedures.  One  of  the  0 / S  dependent  external 
procedures,  Call  SCI,  was  defined  hv  this  investigation  and 
the  remainder  are  supplied  with  the  DX-10  9/S.  There  are 
also  several  standard  procedures  that  are  automatically 
included  at  compile  time  to  implement  the  many  standard 
characteristics  of  the  Tl-Pascal  language.  A  few  of  the 
standard  procedures  will  he  shown  on  the  structure  charts  to 
emphasize  the  functions  they  provide. 

The  0/S  interface  procedures  appear  along  the  bottom  of 
the  structure  charts.  Connections  between  the  interface 
procedures  and  their  calling  modules  are  indicated  by  the 
alphabetic  code  in  the  small  circles.  «VS  modules  called  by 
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the  interface  procedures  are  indicated  in  the  large  open 
circles.  The  functions  of  the  interface  modules  are 
described  below. 

P_ut_msg.  Putmsg  is  a  DX-10  dependent  external  Pascal 
procedure  that  provides  an  interface  with  the  Emulator 
Command  Queue.  A  packed  array  of  variable  size  is  passed  to 
the  procedure.  The  procedure  places  the  array  in  the 
Emulator  command  Intertask  Message  Queue  (IMQ).  Putmsg  uses 
Supervisor  Call  (SVC)  1C. 

Getmsg .  Getmsg  is  a  DX-10  dependent  external  Pascal 
procedure  that  provides  an  interface  with  the  Emulator  log 
IMQ.  The  procedure  fetches  a  message  from  the  IMQ  and 
passes  it  to  the  calling  module.  Getmsg  uses  SVC  ID. 

Delay.  Delay  is  a  DX-10  dependent  external  Pascal  procedure 
that  suspends  the  calling  program  for  a  period  equal  to  some 
multiple  of  50  milliseconds  (ms).  The  prodedure  call  is 
typically  used  when  the  calling  module  wants  to  wait  for  a 
period  time  before  checking  for  the  arrival  of  a  protocol 
message.  Use  of  the  Delay  procedure  reduces  the  amount  of 
processor  time  expended  while  waiting  for  a  response. 
Otherwise,  the  R-S  command  module  would  continually  attempt 
to  check  the  Log  Queue  for  the  arrival  of  the  Protocol 
file.  The  Delay  procedure  uses  SVC  02. 

Rjiad  and  Wj2.it  £ .  The  Read,  Readln,  Write,  and  Writeln 
procedures  are  standard  Tl-Pascal  procedures  needed  to 
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implement  the  basic  Tl-Pascal  language.  They  are  included 
in  the  structure  charts  to  emphasize  that  the  R-S  command 
modules  must  access  data  files  and  devices. 

Call  SCI .  Call  SCI  is  an  external  Pascal  procedure  that  was 
defined  by  this  investigation.  The  procedure  interfaces 
with  S$BIDT  to  provide  a  means  of  executing  SCI  in  the  batch 
mode  as  described  in  previous  chapters. 

F i n d s yn .  Findsyn  is  a  DX-10  dependent,  external  Pascal 
procedure  that  returns  the  value  of  a  system  or  user  defined 
synonym.  Synonyms  provide  a  convenient  means  of  storing 
parameters  that  will  be  constant  from  one  network  command  to 
another.  Information  that  is  constant  from  one  network 
command  to  another  is  stored  in  synonyms.  Another  advantage 
of  synonyms  is  that  they  can  be  used  as  variables  in  Command 
Procedure  (PROC)  files. 

Findsyn  calls  0/S  modules  S$GTCA,  S$SETS,  S$PTCA,  and 
S$RTCA.  S$GTCA  (Get  Terminal  Communications  Area)  opens  the 
TCA  to  other  S$  modules.  S$MAPS  finds  the  requested  synonym 
and  returns  its  value.  SSRTCA  (Release  TCA)  closes  the 
TCA. 

Storesyn .  Storesyn  is  a  DX-10  dependent,  external  Pascal 
procedure  that  sets  a  synonym  to  a  requested  value. 
Storesyn  is  used  to  set  synonym  values  that  are  subsequently 
fetched  using  Findsyn.  Storesyn  uses  0/S  modules  S$GTCA, 
S$SETS ,  S$PTC A ,  and  S$RTCA.  S$SETS  (Set  Synonym)  sets  a 
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synonym  to  a  newly  specified  value.  S$PTCA  (Put  TC A ) 
installs  the  new  or  changed  synonym  in  the  TCA. 

T a^ k i^d  .  Taskid  is  a  DX-10  dependent,  external  Pascal 
procedure  that  fetches  the  runtime  ID  of  the  calling  task. 
FORENET  and  BACKNET  use  their  runtime  IDs  as  a  unique 
identifier  of  the  Log  Queue.  Taskid  uses  SVC  2E. 

The  preceding  paragraphs  under  "Overview"  have 
described  charcter istics  of  the  network  software  design  that 
are  common  to  FORENET  and  BACKNET.  The  next  two  sections 
describe  characteristics  that  are  unique  to  FORENET  or 
BACKNET. 

FORENET 

FORENET  is  the  local  program  responsible  for 
cooperating  in  the  execution  of  all  network  commands  except 
Network  Transfer  Program  File  (NTPF).  The  local  BACKNET 
(BN1)  particpates  in  the  execution  of  NTPF.  Upon  execution, 
FORENET  fetches  commands  and  parameters.  For  all  commands 
except  Network  Initialize  (NI)  and  Network  Quit  (NQ),  BN2  is 
executed  with  S*$BID  Emulator  command  and  parameters  are 
passed  to  BN2  with  the  Parms  file.  NI  and  NQ  are  performed 
locally  only,  and,  therefore,  they  do  not  need  the 
cooperation  of  BN2.  If  the  command  is  NTPF,  FORENET 
terminates  after  executing  BN2.  For  all  commands  except 
NTPF  and  after  the  link  has  been  initialized,  control  is 
passed  to  one  of  the  R-S  command  modules  which  performs  the 
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required  command  functions. 

All  of  the  FORENET  modules  except  the  0/S  interface 
modules  are  described  briefly  in  this  section.  There  is  a 
one-to-one  correspondence  between  most  of  the  modules  and 
the  processes  defined  by  the  software  analysis  in  Chapter  3* 
The  only  exception  is  that  the  Interpret  Command  process  has 
been  divided  into  four  modules:  Get  Comd ,  Get  Parms,  Execute 
BN2,  and  Send  Parms. 

Get  Comd .  The  first  action  of  FORENET  is  to  call  Get  Comd. 
The  Get  Comd  fetches  an  integer  that  represents  the  network 
command  from  a  special  TCA  storage  location.  The  storing  of 
the  integer  is  an  ancilliary  result  of  the  The  .BID 
primitive  is  followed  by  a  SCI  variable  known  as  "CODE". 
CODE  is  set  to  an  integer  value  representing  the  network 
command.  For  instance,  CODE  is  set  to  1  for  NI,  2  for  NLON , 
and  3  for  NTF.  Get  Comd  fetches  the  value  of  CODE  by 
calling  S$GTCA  to  gain  access  to  the  TCA,  S$STAT  to  get  the 
value  of  CODE,  and  S$RTCA  to  release  the  TCA. 

Get  Parms .  The  Get  Parms  module  fetches  the  parameters 
stored  in  the  TCA  by  SCI.  Again,  access  is  gained  to  TCA 
with  a  call  to  S$GTCA.  Subsequently,  S$PARMS  is  called  to 
get  the  value  of  a  parameter.  The  parameters  are  stored  in 
a  sequential  order  corresponding  to  the  order  in  which  they 
were  acquired.  A  particular  parameter  is  fetched  by  passing 
an  integer  that  corresponds  with  the  command  parameter's 
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placement  in  the  TCA  parameter  table. 

Get  Parms  also  fetches  the  runtime  IDs  of  FORENET  and 
the  Emulator.  Get  Parms  calls  Taskid  and  Findsyn  to  get  the 
runtime  IDs  of  FORENET  and  Emulator,  respectively.  Get 
Parms  will  not  call  Findsyn  if  the  command  is  NI  because  the 
synonym  for  the  Emulator  runtime  ID  will  not  have  been  set 
by  the  Log  On  module  yet. 

Initialize  Link.  Initialize  Link  sets  a  control  variable 
that  indicates  whether  Execute  BN2  or  Send  Parms  should  be 
called.  Execute  BN2  is  called  for  all  commands  except  NI 
and  NQ.  Send  Parms  is  called  for  all  command  except  NI,  NQ, 
and  NTPF . 

Execute  BN2 .  BN2  is  executed  with  a  S*$BID  command  to  the 
Emulator.  The  S*$BID  command  includes  a  32  bit  word  that 
becomes  available  to  BN2  as  a  special  parameter.  Execute 
BN2  sets  the  parameter  to  the  same  integer  value  as  CODE. 
Initialize  Emulator.  This  module  initializes  the  Emulator 
by  commanding  it  with  an  ANS  (answer)  command.  The  Emulator 
is  executed  prior  to  the  call  to  Initialize  Emulator  by  a 
X3780  SCI  command  in  the  NI  PROC.  The  NI  PROC  also  contains 
a  STS  command  that  results  in  the  Emulator  status  being 
placed  in  the  STS  List  file.  Initialize  Emulator  determines 
the  runtime  ID  of  the  Emulator  from  the  STS  List  file  and 
sets  a  synonym  to  the  runtime  ID  value  by  calling  Storesyn.- 
The  module  communicates  status  to  the  user  and  the  Net  Log, 
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and  terminates. 


Log  On .  The  Log  On  module  records  the  user  information  in 
the  Net  Log  and  communicates  with  the  remote  Log  On  to 
verify  that  the  log  on  activities  are  being  accomplished  at 
the  remote  end  as  well.  When  the  command  functions  are 
complete,  status  is  communicated  and  the  module  terminates. 
Send  Sequential  File.  The  Send  Sequential  File  module  sends 
a  file  to  the  remote  site  by  commanding  the  Emulator  to  send 
the  specified  file.  After  the  module  receives  confirmation 
from  the  remote,  cooperating  module  that  the  file  has 
arrived  properly,  status  is  logged  and  the  module 
terminates . 

Receive  Sequential  File.  The  FORENET  Receive  Sequential 
File  is  called  when  FORENET  has  requested  that  a  remote  file 
be  transferred  to  the  local  site.  The  module  communicates 
with  remote  module  during  the  transfer  and  monitors  the  Log 
Queue  to  determine  when  the  transfer  is  complete.  When  the 
transfer  is  complete,  Receive  Sequential  File  notifies  the 
remote  module  and  follows  the  normal  termination  procedure. 
Execute  Task .  The  Execute  Task  module  monitors  the  progress 
of  the  cooperating  module  at  the  remote  site.  The  module 
reports  status  to  the  user  periodically.  When  the  remote 
module  reports  that  the  remotely  executed  user  program  has 
completed  execution,  the  FORENET  Execute  Task  module  logs' 
status  and  terminates. 
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E_x  e£U_t  e  B_a_tch.  The  Execute  Batch  module  monitors  the 
activities  of  the  BN2  Execute  Batch  module.  When  the  module 
receives  a  message  from  BN2  indicating  that  the  User  Batch 
file  has  completed  execution,  Execute  Batch  sends  its  usual 
status  messages  and  terminates. 

Compile.  The  Compile  module  monitors  its  complementary 
module  at  the  remote  site.  Commun ications  are  maintained 
between  the  modules  while  the  remote  module  accomplishes  the 
primary  objectives  of  the  NCOMP  command.  When  the  remote 
compile  is  complete,  the  Compile  module  terminates. 

Link  Edit .  The  Link  Edit  module  monitors  the  actions  of  the 
remote  Link  Edit  module.  When  the  link  edit  is  complete, 
the  module  terminates. 

Log  Off.  The  Log  Off  module  records  user  information  and 
terminates  communications  between  the  Emulators.  The  user 
information  that  must  be  logged  is  obtained  by  calling 
Findsyn.  Emulator  communications  are  terminated  by 
commanding  the  Emulator  with  a  TERM  command.  The  TERM 
command  also  terminates  execution  of  Emulator,  necessitating 
reinitialization  of  the  Emulator  with  a  NI  SCI  command.  The 
NI  command  is  contained  in  the  NLOFF  PROC  after  the  .BID 
primitive  and,  therefore,  is  executed  after  the  Log  Off 
module  has  terminated. 

T e£m ^n a t e  Emulator  .  The  Terminate  Emulator  module- 
terminates  the  Emulator  by  commanding  the  Emulator  with  a 
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TERM  command. 


BACKNET 

The  BACKNET  program  usually  executes  as  the  remote 
cooperating  program,  but,  when  the  NTPF  command  is  received , 
both  the  local  and  remote  BACKNETs  must  be  executed.  The 
local  BACKNET  is  know  as  BN1  and  the  remote  BACKNET  is  known 
as  BN2.  All  of  the  BACKNET  modules  except  the  0/S  interface 
modules  are  described  in  this  section. 

Get  Comd .  The  Get  Comd  module  fetches  the  32  bit  word  that 
arrived  in  in  conjunction  with  the  S*$BID  command.  The  work 
represents  the  network  command  and  is  fetched  by  calling  the 
SVC$  module.  The  SVC$  module  uses  the  Get  Parameter 
Supervisor  Call  (SVC  17)  to  obtain  the  word. 

Get  P a rms .  The  Get  Parms  receives  the  the  Parms  file  from 
either  FN1  or  BN1.  The  parameters  are  always  passed  from 
the  local  to  the  remote  end  of  the  link.  For  all  commands 
except  NTPF  the  file  is  passed  from  FN1  to  BN2.  For  NTPF 
the  file  is  passed  from  BN1  to  BN2. 

Initialize  Link.  The  Initialize  Link  module  processes  the 
command  and  its  parameters  which  were  received  from  the 
local  site  to  determine  whether  the  Execute  3N1  and  Send 
Parms  modules  should  be  called.  The  modules  are  called  only 
if  the  command  is  NTPF. 

Log  On.  The  BACKNET  Log  On  module  performs  the  same 
functions  as  the  FORENET  Log  On  module. 


Send  Program  File .  The  Send  Program  File  module  resides  in 
BACKNET  only.  The  module  passes  a  program  file  from  the 
local  to  the  remote  end  of  the  link  if  the  module  is  in  BN1, 
or  vice  versa,  if  the  module  is  in  BN2.  In  either  case,  the 
module  executes  a  Backup  Directory  (BD)  Batch  file  by 
calling  Call  SCI.  At  the  completion  of  the  BD  Batch  file, 
the  specified  program  file  has  been  converted  to  a 
sequential  file,  and  parameters  and  control  are  passed  to 
the  Send  Sequential  File  module.  The  Send  Sequential  File 
cooperates  with  its  complementary  module  to  transfer  the 
sequential  file  across  the  link.  When  the  sequential  file 
has  been  received  at  the  opposite  end  of  the  link,  control 
returns  to  the  Send  Program  File  which  monitors  its 
complementary  module  executing  a  Restore  Directory  (RD) 
Batch  file.  When  the  program  file  has  been  properly 
installed,  the  module  terminates. 

Receive  Px£g£am  Fi__^e.  The  Receive  Program  File  module 
resides  in  BACKNET  only  and  participates  in  the  transfer  of 
a  program  file.  The  module  monitors  the  execution  of  the  BD 
Batch  file  by  its  cooperating  module.  When  the  program  file 
has  been  converted  to  a  sequential  file,  parameters  and 
control  are  passed  to  the  Recieve  Sequential  File  module. 
When  the  transfer  of  the  sequential  file  is  complete, 
control  returns  to  the  Receive  Program  File  module  which 
executes  a  RD  Batch  file.  The  completion  of  the  RD  Batch 
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execution  marks  the  end  of  the  NTPF  command  functions  and 
the  module  terminates. 

Send  Sequential  File.  The  BACKNET  Send  Sequential  File 
module  cooperates  with  a  Receive  Sequential  File  in  FORENET 
or  BACKNET,  depending  on  whether  it  is  executing  a  NTF  or 
NTPF  command. 

Receive  Sequential  File.  The  BACKNET  Receive  Sequential 
File  module  cooperates  with  a  Send  Sequential  File  module  in 
FORENET  or  BACKNET,  depending  on  whether  it  is  executing  a 
NTF  or  NTPF. 

Execute  Task.  The  primary  objectives  of  the  NXT  command  are 
accomplished  in  the  BACKNET  Execute  Task  module.  The  module 
executes  the  NXT  Batch  file  by  calling  the  Call  SCI  module. 
The  Module  periodically  checks  the  status  of  the  task 
exection  by  executing  a  STS  Batch  file  and  reading  the  STS 
List  file.  The  module  keeps  the  cooperating  module  informed 
of  the  progress  of  the  execution  through  frequent 
communications  via  the  Protocol  files.  When  the  task 
execution  has  completed,  the  module  sends  a  status  message 
to  the  cooperating  module  and  terminates. 

Execute  Batch.  The  Execute  Batch  module  executes  the 
designated  User  Batch  file  by  calling  the  Call  SCI  module. 
The  module  monitors  the  batch  execution,  sends  status  to  the 
cooperating  module,  and  terminates  when  all  command 
functions  have  been  accomplished. 


Compile.  The  Compile  module  builds  a  NCOMP  Batch  file  with 
the  NCOMP  command  parameters  and  executes  the  batch  file  by 
calling  Call  SCI.  Compile  monitors  the  progress  of  the 
compile  by  reading  the  Compile  Message  file.  When  the 
compile  is  complete,  the  module  follows  the  normal 
termination  procedure. 

Link  Edit.  The  Link  Edit  module  builds  a  NLINK  Batch  file 
and  executes  it  by  calling  the  Call  SCI  module.  Link  Edit 
monitors  progress  by  reading  the  Link  List  file.  When  the 
Link  Edit  is  complete,  the  module  terminates. 

Log  Off.  The  BACKNET  Log  Off  module  perorms  the  same 
functions  as  the  FORENET  Log  Off  module. 

Summary 

This  chapter  has  described  the  design  of  the  network 
software  programs  FORENET  AND  BACKNET.  The  structure  of  the 
design  was  illustrated  with  structure  charts  that  depicted 
program  modules  and  their  inter  relations .  Modules  were 
defined  to  perform  major  functions  such  as  executing  a 
particular  network  command.  Each  module  that  implemented 
R-S  functions  was  given  control  of  its  input  and  output 
functions.  By  controlling  its  communications,  a  module 
achieves  the  independence  it  needs  to  execute  R-S  functions 
efficiently . 
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V.  Results  and  Recommendations 

The  primary  objective  of  this  investigation  was  to 
design  a  r e sour c e- sh a r i n g  (R-S)  network  link  that  would 
allow  an  operator  or  user  program  to  access  remote  computer 
resources  by  entering  simple  network  commands  at  the  local 
computer.  The  design  was  constrained  to  use  existing 
hardware  and  software  modules  as  applicable.  An  R-S  network 
link  design  that  was  specialized  to  accommodate  existing 
model  990  computers  was  accomplished  by  this  investigation. 
The  design  results  are  summarized  in  the  section.  The  final 
section  contains  recommendations  for  refining  and 
implementing  the  design. 

Design  Results 

The  design  that  resulted  from  this  investigation 
consists  predominantly  of  existing  hardware  and  software 
modules.  The  goal  of  the  design  was  to  combine  the  existing 
capabilities  in  a  manner  that  made  them  appear  to  the  user 
to  be  two  comprehensive,  cooperating  R-S  processes  capable 
of  performing  all  of  the  required  functions.  Two  new 
modules,  the  programs  FORENET  and  BACKNET,  were  designed  to 
accomplish  the  task  of  coordinating,  or  automating,  the 
execution  of  the  existing  capabilties.  Also,  a  new 
interface,  the  S$BIDT  interface,  was  designed  that  allows 
access  to  any  resource  controlled  by  the  DX-10  operating 
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system. 

The  R-S  programs  FORENET  and  BACKNET  perform  the 
required  R-S  functions  by  coordinating  the  execution  of 
capabilities  under  their  control.  The  programs  are  able  to 
coordinate  their  activities  by  exchanging  messages  as 
prescribed  by  R-S  protocols. 

Commun ications  are  implemented  through  a  combination  of 
several  existing  modules.  The  most  important  of  these 
modules  is  the  3780  Emulator.  The  Emulator  provides  the 
communications  interface  to  the  R-S  programs.  The  basic 
capability  of  the  Emulator  is  to  transfer  files.  Therefore, 
the  communications  technique  used  by  the  R-S  programs  is  to 
place  protocol  messages  in  various  files  and  to  command  the 
Emulator  to  transfer  the  files.  The  protocol  messages 
enable  each  program  to  decide  which  protocol  state  to  enter 
next.  A  program  determines  its  next  action  by  comparing  its 
current  stat«  and  the  messages  received  from  its  cooperating 
process  against  the  protocols,  or  logical  rules,  that  are 
inherent  in  the  logical  structure  of  the  program. 

The  R-S  network  link  designed  is  capable  of  performing 
complex  R-S  functions  after  receiving  only  a  simple  mnemonic 
command.  The  cooperating  R-S  processes  actively  communicate 
to  coordinate  the  execution  of  numerous  subfunctions 
necessary  to  fulfill  the  goals  of  the  requested  R-S 
function.  If  an  error  is  detected  the  processes  attempt  to 
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recover.  However,  if  recovery  attempts  also  fail  the 
processes  proceed  to  achieve  a  well  defined  abnormal 
termination  and  report  the  error  to  the  user. 

Recommendations 

The  primary  recommendation  is  that  the  design  contained 
in  this  report  be  implemented.  Throughout  the  design,  ease 
of  implementation  was  a  major  consideration. 

The  network  commands  were  defined  in  a  manner  very 
similar  to  the  the  operating  system  (SCI)  commands  are 
implemented.  The  advantage  of  defining  the  network  commands 
in  that  manner  is  that  ample  documentation  (Ref  18)  is 
available  to  aid  in  the  implementation.  Similarly,  the  R-S 
programs  were  refined  as  Command  Processors  as  defined  in 
operating  system  documentation.  Numerous  operating  system 
routines  that  enhance  interactive  operation  are  available  to 
programs  that  are  so  defined. 

Before  FORENET  and  BACK MET  are  implemented  it  is 
recommended  that  the  modularization  defined  in  Chapter  4  be 
extended  to  at  least  one  more  level.  The  functions  that 
must  be  carried  out  by  each  module  are  complex  enough  that  a 
single  corresponding  Pascal  procedure  would  be  difficult  to 
read  and,  therefore,  would  also  be  difficult  to  test  and 
debug . 

It  is  also  recommended  that  the  protocol  designs 
described  in  Chapter  3  be  refined.  The  protocols  described 
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represent  a  preliminary  design.  Since  protocols  determine 
the  flow  of  control  between  cooperating  processes,  they 
should  be  more  precisely  documented  before  an  attempt  is 
made  to  code  them.  References  6  and  16  provide  excellent 
background  information  on  the  subject  of  data  communication 
protocol  design. 
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This  appendix  contains  the  program  listings  used  to 
demonstrate  the  S$BIDT/SCI  interface. 

The  first  program  listing  on  pages  111  and  112  is  the 
Pascal  program  CALLP$  that  demonstrates  how  a  Pascal  program 
calls  the  procedure  Call  SCI,  defined  previously  in  Chapter 
4.  The  external  procedure  SYSBID  found  in  the  Pascal  source 
listing  corresponds  to  Call  SCI. 

The  next  program  on  pages  113  through  115  is  an 
assembly  code  listing  which  is  structured  as  the  TI  Pascal 
Compiler  would  structure  an  external  procedure  (Ref  19). 
When  CALLP$  calls  SYSBID,  the  parameters  are  placed  in 
locations  determined  by  compiler  characteristics.  SYSBID 
"knows"  where  the  parameters  are  placed  and  rearranges  them 
to  locations  where  S$BIDT  expects  to  find  them. 

The  listing  on  page  116  is  the  demonstration  data  read 
by  CALLP$. 

The  listing  on  page  117  is  the  contents  of  the  batch 
file  that  SCI  reads. 

The  listing  on  page  118  is  the  batch  listing  which 
results  from  SCI  reading  the  batch  file.  The  batch  file 
contains  a  .SHOW  primitive  designating  the  data  file  which 
was  read  by  the  Pascal  program.  The  .SHOW  primitive  causes 
the  indicated  file  to  be  read  into  the  batch  list.  The  data 


on  page  116  can  be  found  in  the  batch  list,  demonstrating 
that  SCI  was  executed  in  the  batch  mode. 

The  following  information  is  taken  directly  from  a  TI 
information  sheet : 

S$BIDT  SUBROUTINE 

Cooperating  tasks  written  in  assembly  language  that  do 
not  call  the  S$  subroutines  may  execute  each  other  by 
including  an  Execute  Task  SVC  in  the  calling  task.  When 
both  tasks  are  in  the  same  program  file,  the  LUNO  is  already 
assigned.  Otherwise,  the  LUNO  may  be  assigned  by  an 
interactive  SCI  command,  by  a  batch  mode  SCI  command,  or  by 
an  I/O  Utility  SVC  in  the  calling  task  (preceding  the 
Execute  Task  SVC  ) . 

The  S  $  B I D  T  subrouting  should  be  used  to  call  a 
cooperating  task  that  calls  S$  subroutines.  Either  S$GTCA 
or  S$NEW  must  be  executed  prior  to  calling  SSBIDT.  The 
S$BIDT  subroutine  uses  RO  to  return  a  completion  code.  A 
value  of  zero  is  returned  when  the  subroutine  completes 
satisfactorily;  a  nonzero  value  is  returned  when  an  error 
has  occurred.  Prior  to  callinig  S$BIDT,  the  user  must  place 
the  following  values  in  registers  R1  through  R3: 

R1,  left  byte  -  Task  ID  of  task  to  executed. 

R1,  right  byte  -  LUNO  of  program  file  that  contains  the 

task . 

R2  -  Address  of  parameter  table,  or  zero  when  ther  are 


no  parameters. 

R3,  left  byte  -  Code  value,  or  zero. 

R3,  right  byte  -  Flags: 

Bits  8-11  -  Set  to  zero. 

Bits  12  -  set  to  one. 

Bits  13-15  -  set  to  zero.  The  parameter  table 
address  in  R2  is  the  address  of  a  table  of  words  that 
contain  addresses,  followed  by  a  work  that  contains  zero. 
Each  address  in  the  parameter  table  is  the  address  of  a 
parameter  in  the  following  format: 

Byte  0  -  Nunber  of  characters  in  parameter. 

Byte  1  through  n  -  characters  of  parameter.  When  a 
parameter  has  a  null  value,  set  byte  0  of  the  parameter  to 
zero. 

The  code  value  in  the  left  byte  of  R3  is  an  integer  in  the 
range  of  0  through  255  that  may  be  accessed  as  a  binary 
value  by  the  called  task.  If  the  task  does  not  require  a 
code  value,  enter  zero. 

Subroutine  S$BIDT  executes  an  Execute  Task  Supervisor  call. 
The  values  in  R1  and  the  right  byte  of  R3  are  placed  in  the 
appropriate  bytes  of  the  supervisor  call  block.  That  is, 
the  task  ID,  LUNO,  and  flags  are  those  values  required  for 
an  Execute  Task  SVC.  The  SVC  also  passes  the  parameters  and 
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the  code  value  to  the  called  task.  The  called  task  obtains 
the  parameters  by  calling  the  P$PARM  subroutine. 

Subroutine  S$BIDT  is  called  as  follows: 

BLWP  @S$BIDT 


(**W I DELIST*) 

PROGFrAM  C  ALLP %  ? 

CONST 

SL-40? 

LEN0TH=G9; 

TYPE 

STF:  I  NO=P AC  KED  ARRAY  Cl..  SL  3  OF  CHAR? 


VAR 

CMDF I LEs STRING? 

LSTF I LE: STRING? 

FLAGS  INTEGER; 

TASK  IE*:  INTEGER; 

C-ODEs  INTEGER; 

ERROR: INTEGER; 

NUMBS  INTEGER? 

PFLUN0: INTEGER; 

SRCFILEsTEXT; 

V» INTEGER; 

Ss INTEGER; 

PROCEDURE  SYSBIQ  (TASK ID* INTEGER5  PFLUMOs INTEGER; 

I NACNM ; STR I NO ;  LAC  KM : STR I MG 5 
CODE:  INTEGER;  ERR.GF: s  INTEGER; 

LENGTH? INTEGER;  FLAGS  INTEGER > ;  EXTERNAL? 


PROCEDURE 


I  OB  I D  <  TASK  ID?  I NTEGER 5  DFLUMO  s  I NTEOER  *  VAR.  I  NACNM  ;  S 
VAR  LSTACNM 5  STRING*  CODE:  INTEGER*  VAR  ERROR. s  I 
LENGTHS  INTEGER)  ; 


PROCEDURE  S H I FTONE < VAR  STR : STR I NO  > ; 


CONST 

BLANK  =  ' 

VAR 

NEW: STRING; 


BEGIN 


FOP.  N  5  =  1  T 0  SL  DO 
NEWCN3  :=  BLANK; 

S  *  ss  t; 

V  :=  2? 

FOR  N  :=  I  to  EL- I  DO 
BEGIN 

NEWCV3  s=  STR IS] ; 
S  : =  3+i; 

V  **  V+l 
END? 

STR  :=  MEW 

END? 


•  BEGIN 


Page 


SHI FTONE ( I NACNM) ? 


WRITELN'  '  TMar.'iMs-" .  TMirtJMi  • 
SH!FTOr':”  L  :  ~w C  mm  >  • 

UjCTT-i  Mr  , 


BEGIN 

RESET (SRC FILE) ; 

I F  NOT  EOF  ( S  PC  F I LE  >  THEN 

READLM  /  ■:  cr  FILE  -  T^EK;i  n  \  ; 

IF  NOT  EOF  i.  SRC  c  ILE  >  THEN 

READLM  C  r  F'C  F  I  LE  -  FL'JMO  '•  ? 

IF  NOT  EOF  < SRC  F I LE  >  THEN 

READLM  ( S  PC  F I  LE  ,  C  MD^  I  LE )  ; 
IF  MOT  p  n p  /  c  t  ^  y  » i— i i  ^  '>  ,i 


1 


READLM 
IF  NOT  EOF (SRC 
READLM (CP 
IF  NOT  EOF < SFO 
READLM ( SR 


t  c  f.  c  F I  LE  •  L  E  TF I  LE  > 
cr  ti_E  ~HEM 
C~ILE-  C  D  E )  * 

-ILE>  ~HEM 


WRITELN  (  ■  TAS'-  ID=  , TASK IDs  3 1  "  PFLUNO*' ,  F'FLUNO:  3  >  ? 

WRITE (  '  CMDcrILE=  11  ; 

WRITELN(  CMDFILE  '•  : 

WRITE' •LSTFILE=  ' ? 

WRITELN ( LS T“ ILE  > • 

WRITELN'.  CODE=  -CODE'  ?,  *  LENGTH*  *%  LENGTHS  3,  •'FLAG**'  »  FLAG*  3  >  ? 
IOBID  (  TAS1-  I  D  -  =-LC  ••■-:*-  C  ME  FILE?  LSTFILEr  CODE:  ERROR  -  LENGTH)  ? 
SYSBID'.TAS)  IE1-  =  ~L:JMO-  CWDFILE:  LS7FILE,  CODE?  ERROR.  LENGTH,  FLAG)  ’ 
WRITELN  '  ••£=  =  .:*=-•  •  ERROR  ) 


END. 


OPEN 


DATA  0 

byte  o,:  ai 

DATA  0. Or  0.0 


binhex  byte  :  c 

BYTE  0 

OUTHEX  BYTE  0 » 0 -  0 - O 
WRTHEX  DATA  0 

data  :-&ai 

DATA  0 

data  ^OUTHEX 

DATA  0 
DATA  4 

WRTCR  DATA  0 

DATA  DBA 1 
DATA  0 
DATA  @CRT 

data  0 

DATA  2 

CRT  DATA  DOAOD 

WRTIM  DATA  0 

DATA  DBA 1 
DATA  0 
DATA  0 
DATA  0 
DATA  40 


WRTL 

DATA 

\\ 

DATA 

>BAl 

DATA 

o 

DATA 

o 

DATA 

o 

DATA 

40 

BOT 

cr.ij 

p.o 

ARO 

enn 

-  -  - 

TASK ID 

FmIJ 

w  r« 

PFUJNO 

FijlJ 

w  *"•* 

I MAC MM 

EO'J 

\ <i 

lacnm 

Cnl.l 

CODE 

EOO 

c>  c-i%*  4 

ERROR 

PnlJ 

flCi".*:;'/; 

length 

EO'J 

‘3’  "**  -  ^ 

FLAG 

EQ'J 

ARO*  ”'0 

REF 

emt^m.ret^m 

REF 

StBIDT 

REF 

SSMEM 

TEXT  'SYS9ID  " 
DATA  2 
DATA  L2 


DATA 

ncrtr 


LI 

-  v  mm 


DATA 

MOVB 

MOVE* 

MOVB 

SWPB 

MOVB 

LI 

LI 

LI 

LI 

A 

A 

MOV 

A 

MOV 

MOVB 

SWPB 

MOVB 

BLWP 

BLWP 

MOV 

MOV 

XOP 

XOP 

XOP 

XOP 

MOV 

XOP 

XOP 

XOP 

MOV 

XOP 


— Kir,j u-f  i  I  DOT  >  -OI  •'■AC  MM  (  E OT  >  • 

'  '  E"-’”  ’>  -  OLACNM  *  BO^" ) 

OFFLUi'IO-'-l  1  EOT  >  ,  P.  1 
Pi 

A'i H.  I D+ 1  ( EOT  >  -  R  1  „  „ 

po,::;  LOAD  OIE-FLACHENT  OF  PA  FROM  RO  INTO  R2 

R4 i I MAC MM 
R5i LAC MM 

RA .  >0 

P9  p.-?  ADD  ADDRESS  OF  R0( BOTTOM  OF  E-TACK)  TO  R2 

p_4  p.r.ri  inriPCQ':,  r.p  r.*>  TO  RELATIVE  ADDR  Oe  R4 

P4.  fi>WRTIN+i.  MOVE  ADDREE  E  OF  I N  AC  MM  TO  MRTIN  EVC  BLOCK 
p-3.ps  ADD  ADDREE S  OF  RO  TO  RELATIVE  ADDR  OF  PS¬ 

PS,  ©MRTL*6 

©FLAO+1 'BOT> ,  RS  SET  "FLAG"  VALUE  IN  RIGHT  BYTE  OF  R 
R3 

OCr|DE-*- 1  1  EOT '  ,  R3  SET  "CODE"  VALUE  IN  LEFT  BYTE  OF  Ru 
OS 5 NEW 
OE'iB  I DT 

opppnp  <  pijT  >  ,  F:E:  MOV  ADDRESS  OF  ERROR  INTO  RS 
RO,  *FE' 

00 FEN ,  IS 
OBTNHEX , IS 
©WRTweX  ,  IS 
OWRTC  c' ,  1 S 

R 1  -  R<.' 

OB INHEX  -  IS 
»i.jrtrf  «; .  15 

OWRTC P,  IS 
R2 ,  RO 

(3PTMW=Y  .  15- 


XOP 

®MRTUEX- IS 

XOP 

ewRT»: » r  is 

MOV 

P  ,  h1  i  ^ 

XOP 

OBIMHEX  -  IS 

XOP 

®WRT*^E X  •  IS 

XOP 

ftWRT.;  P  -  15 

MOV 

R4  -  RA 

XOP 

OBIMHEX : IS 

XOP 

ei,i::Turv ,  i5 

XOP 

OWRTCc-  IS 

MOV 

RS  -  c'‘'’ 

XOP 

OBIMHEX • 1 S 

XOP 

®WRTUEy -  IS 

XOP 

OWRTC R* IS 

MOV 

RA  -  RO 

XOP 

OB  I  NHE  Y  -  1 S 

XOP 

(jM.JRTUry  .  15 

XOP 

OWRTC  P  ?  IS 

MOV 

p'v  ^  Pm 

XOP 

OB  INHEX  -  IS 

XOP 

OWFTHE Y  ,  IS 

XOP 

OWRTC R-  IS 

MOV 

»TA-^In,c"r'>  •  PO 

XOP 

©B INHEX r IS 

XOP 

OWRTHEX, IS 

XOP 

OWRTCR,  is- 

MOV 

©PFLUNO ( R° > , RO 
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L2 


XOP 

OP  I MUE  V  -  1 0 

vr.c 

r.1  ,  |  cr 

MOV 

r*r_  nr.c  f  ^  r.  .  .  - 

XOP 

OP  I  '  HEX  •  t  5 

XOP 

OUR T RE  X ,  15 

XOP 

©WRTCRt  1*5 

MOV 

P^t‘|  |K‘  /  N  . 

MOV 

♦sj# ,  c*r» 

XOP 

OBINHE* -  1 5 

XOP 

OURTHET •  15 

XOP 

^  Lj  fv  T  *  C’  .  1  ^ 

MOV 

OLE  NOTH  1  P 'r-  > 

XOP 

OB  IMRE  '  15 

XOP 

OWRTU-V . 1 - 

XOP 

OURTC  P:  -  15 

MOV 

» c  p  l.  A  C*  •  ^ 

XOP 

Op  T  Mi-IT  v  .  i  — 

XOP 

OWRTHEX -  15 

XOP 

OURTCPr  15 

XOP 

OUPT  ILL  15 

XOP 

OURTCR-  15 

XOP 

OURTL i  15 

XOP 

OUR  TCP:  ?  15 

B 

OPET*M 

END 

move  ADDRESS  0r  Ec:POP: 
MOVE  ERROR  VALUE  I MTO 


INTO  F:3 
F:0 
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PAT'> 

^cu'il.J  tip  p  cz-‘\  V  .  MCLEOD-  r-l‘  ATP 

EBATCH 


Page 


1 


♦  -SCI'? 


<•  <S  - 


T-r  r^r.  *- 


LS  (LIST  SYMOMYM?  '  “  MO 

BATCH  LIST IT-j 0  ACCESS  NAME  ♦*  NULL  ** 

BATCH  IN-UT  ACCESS  NAME  **•  NULL  ** 

STATION  ID  ST 03 

USER  ID  TMM012 

17: 11:5?  MONDAY ?  SEF  0S»  19S0. 

<00020  .  SHOW  AFBSOO .  MCLEOD .  S EC  .  F1»DATA 
#20 
#0 

AFB500 . MCLEOD . XB . CHOW 
AFB500.  MC  LEC'D .  X  B .  L I  ST 

#0 

#0 

<0003>  EBATCH. 

CODE  ♦♦  NULL  ** 

TEXT  *♦  NULL  ** 

LS  (LIST  SYNONYMS)  ?  NO 
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